import dialog vs. application wizard

[Bernd Gehrmann]

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.

Bernd.


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«