New AppWizard Dialog
nolden at kde.org
Sun Aug 12 03:23:59 UTC 2001
On Saturday, 11. August 2001 20:44, you wrote:
> Hello Ralf,
> Hmmm, I have to admit that I didn't really understand your mail. Properly
> because I'm new to KDE programming. So it would be cool, if you could
> the plan in your mind a little bit more.
> This is how I understood you mail:
> 1. Split up the wizard into one .ui-file per page. The pages would have the
> type 'QWidget'.
> (Wouldn't it be better to have all common pages in one .ui-file? What
> is the advantage
> to have them separated?)
Because, usually you separate one dialog from the next to reduce the
complexity of the implementation class. So instead of having one ui file and
one class that inherits from the uic generated class of the ui file (where
you then put your implementation in), you'd have one ui file per page and one
class per page. That makes it more modular and easier to maintain. People can
work independently on the different pages without hassling too much. Also, I
think by this way we could enable the appwizard to use custom plugins of the
developers. The developers could adapt the appwizard to their needs. And we
could even ship updates as plugins for newer stuff that would automatically
plug into the appwizard.
> 2. Every page should have a different graphic except the plugged-in pages.
> (Is this really necessary? What is the benefit of having different
It is less boring and very attractive. A graphic on the page makes it look
unique and the graphics should represent a rough meaning of what's to be done
on the page. Essentially, graphics should allow people to understand the
sense of the page without reading the text except the checkboxes. That is
extremely important as the human thinking has a hard time to differentiate
more than 3 radiobuttons in a group for example. That's the reason why the
kcontrol modules in KDE 2.2 have been redesigned in various parts because the
user was required to think about what he does.
> 3. Class- and filenames should be choosable for specific project types.
> (Which classnames? The main window class?)
For example. But all should be sepeartely namable. See for example how Visual
Studio does it. It gives a pre-set set of file and class names, but it
doesn't force you. The way we did that in KDevelop 1.x and 2.0 is not very
friendly as it requires the user to accept what we provide. The same what
counts on classes is valid for filenames of e.g. php projects as well - and
of course classes/functions in a lot of other stuff that have to be evaluated
when working on the wizard.
> 4. Additional project-type-specific pages should be load as a QCom-plugin
Yes. So we just enable that. The user should be able to configure the
appwizard to his personal needs by a simple way (and also be able to make a
backup and an easy installation of a customization file so in a company, that
process only has to be done once by the admin/project coordinator and give it
to his developers)
> 5. The template files should say which wizard pages should be displayed
Yes, for example. In some respect the wizard follows an internal logic, so
this may be not necessary. Evaluate that while working on that stuff and then
discuss advantages/disadvantages and solutions.
> 6. The project files (.kdevelop) should name the parts that should be
> loaded on startup
> (Don't they do this already?)
I didn't have a look at all internals so I can't answer this right away.
Maybe Sandy can comment on that.
> Please correct and extend these statements...
> > On Saturday, 11. August 2001 14:46, you wrote:
> > > Hi everybody!
> > >
> > > I played a little with the AppWizard-dialog of Gideon. I tried to
> > > gave it a more professional look. So this is my first try. I know
> > > that the text parts still need some polishing. Also you have to
> > > load the pixmap on the left side of the dialog by hand, because I
> > > didn't want the .ui-file get to big.
> > >
> > > Please comment, flame, etc....
> > Good work! Especially the graphics. Now, what is needed, is a somewhat
> > layout here and there. It doesn't meet all the things though,
> > specifically the project-type specific things like classes and filenames
> > should be choosable later. Another thing is that the wizard needs to be
> > split up
> > several parts maybe to reimplement functions that you want to call for
> > modularization, which works in the end the same way as kpersonalizer.
> > (you would need more graphics for the wizard though, and one
> > standard-graphic
> > the to-plug-in-pages for the different project-types).
> > Now, with additional pages, those could be plugged in for the specific
> > project type in Qt 3 as a plugin, if I understand that correctly,
> > on what the user chooses on the first page.
> > Could you make up a draft or something for that ? You could also go ahead
> > start an implementation for that stuff; also the wizard should
> > auto-detect (find out by itself) all project types and the user's
> > self-made templates with their according settings. In the project file it
> > writes it should
> > name the kdevelop parts that should be loaded on project loading by
> > BTW do you have a CVS account yet ?
> > Thanks,
> > Ralf
> > > Christian Loose
> > --
> > We're not a company, we just produce better code at less costs.
> > --------------------------------------------------------------------
> > Ralf Nolden
> > nolden at kde.org
> > The K Desktop Environment The KDevelop Project
> > http://www.kde.org http://www.kdevelop.org
> > -
> > to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body:
> > unsubscribe »your-email-address«
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body: unsubscribe
We're not a company, we just produce better code at less costs.
nolden at kde.org
The K Desktop Environment The KDevelop Project
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel