New AppWizard Dialog

[Ralf Nolden]

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
> mainly
> because I'm new to KDE programming. So it would be cool, if you could
> outline
> 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'.
Correct.
>     (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
> graphics?)
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.

Ralf
>
> Please correct and extend these statements...
>
> Thanks
>
> Christian
>
> > 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
>
> better
>
> > 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
>
> into
>
> > 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
>
> for
>
> > 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,
>
> dependent
>
> > on what the user chooses on the first page.
> >
> > Could you make up a draft or something for that ? You could also go ahead
>
> and
>
> > 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
>
> also
>
> > name the kdevelop parts that should be loaded on project loading by
>
> default.
>
> > 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
> »your-email-address«

-- 
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«