import dialog vs. application wizard

[Ralf Nolden]

Bernd Gehrmann wrote:
> 
> On Sun, 27 May 2001, Ralf Nolden wrote:
> >
> > I would suggest to integrate it into the application wizard. When it
> > comes to importing a project, I think the way it worked was ok by
> > selecting the project type he has. The import function is very important
> > (like the name says :) towards users that want to migrate to KDevelop.
> > Isn't there a rules setup where the IDE automatically loads the
> > components needed for the specific project type and the general ones
> > split from these ?
> 
> No, there is no such thing as a project type. Projects have a language,
> but that's not useful to parametrize the default configuration. A
> GNOME C++ project needs a different documentation set than a terminal
> or KDE C++ project. File groups depend on whether the application is
> GUI or not. The documentation tree is something that must be customi-
> zable on a per-project basis. For example, I want to have the Python
> documentation available in order to browse the embedding api docs.
> That's not the typical case for any non-Python project, but it must
> be possible.
> 
> > Does that make sense ? :)  I think it's now more important to think
> > about how to hide too technically detailed problems like the exact
> > plugin the user needs or kdevelop provides by simplifying and making
> > pre-decisions for the user (such as the average user needs) and giving
> > him a simple method to customize these settings later.
> 
> That's the goal. But the current import dialog doesn't achieve this.
> The application wizard does, but it always generates complete new
> projects and doesn't allow to install a pre-configured project file
> into an existing directory.
Maybe a general configuration for importing projects would help. Then
the user sets up the default environment once per project type; does the
import and that's it. If he *then* has some customization needs, he
should be able to use the configuration dialog of the project to decide
which docs are displayed and which aren't. Most users won't be hassling
with that too much anyway as it's very time consuming to sort this out
what he needs if he has everything in place already, even if that is too
much info like having the KDE books enabled plus the gnome ones if he in
fact only needs the KDE ones. He won't go search for how to disable the
gnome one because it might be that he thinks that the next time he needs
the gnome one he's searching again where to enable that although this
could be done on a per-project base. Someone played with the docs
customization feature of VC++ ?  

Ralf
-- 
Finally, even I have to admit that being myself was the best thing
that ever could have happened to me. - Le Grand Charmeur

**********************************
Ralf Nolden

The KDevelop Project
http://www.kdevelop.org

nolden at kde.org
rnolden at 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«