slim kdevelop

[Alexander Dymo]

On Thursday 07 October 2004 20:03, Ian Reinhart Geiser wrote:
> Also Is it also possible to remove the Diff plugin, and the application
> information console?  Then bind these to projects.
> Next we need to add a filter for the new project wizard.  This filter will
> keep C++ projects from polluting HTML projects, and HTML projects from
> cluttering C++ projects.
> Lastly I am wondering how hard it would be to replace the splash screen
> and the about data for KDevelop, so we can make it say other things.
I already thought about it a bit. My suggestions were on our wiki but wiki is
dead atm, so look at attachment.

> IMHO this would bring us a pretty solid base for making KDevelop a
> platform for building IDEs.


-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine
-------------- next part --------------
1. How would I like to see profiles in KDevelop

Plugin profiles should form a tree-like hierarchy:

KDevelop                                     this keeps a list of enabled plugins for a kdevelop ide which loads w/o profiles
|                                            only global profiles are listed here; this list keeps minumum number of plugins necessary
|
|--Compiled Language Development             this keeps a list of enabled and disabled global and a list of enabled project plugins
|  |                                         for all compiled language 
|  |
|  |--C&C++ Development                      this keeps a list of enabled and disabled global and a list of enabled project plugins
|  |                                         used for c/c++ projects
|  |--Java Development
|  |--etc.
|
|--Scripting Language Development
|  |--Python Development
|  |--etc.
|
|--Full IDE                                  this is a virtual profile - everything is enabled

Profiles inherit settings from their parents but can override them.


2. What is the profile
- Profile is a directory somewhere in $KDEDIR/share/kdevelop/profiles
    example: Full IDE profile would reside in $KDEDIR/share/kdevelop/profiles/KDevelop/Full IDE
- Profile keeps a list of files named <plugin_name>.enable and/or <plugin_name>.disable
    example: in $KDEDIR/share/kdevelop/profiles/KDevelop/Compiled Language Development/C&C++ Development we could have files:
        KDevAbbrev.enable
        KDevFileView.disable
- Plugin is considered as disabled by default. I.e. if for given profile and all its parents there are no <plugin_name>.enable file then
plugin is disabled for the profile.

3. Why profile is not a ini-like file
We need to provide a way for plugin developers to specify which profile this plugin fits to. 
And this would be a matter of installing file <plugin_name>.enable into the profile dir.
For example KDevDocumentation.enable could go to $KDEDIR/share/kdevelop/profiles/KDevelop/Full IDE during installation.


4. How to run KDevelop with a profile.
4.1 at startup: kdevelop --profile=... and plugin controller will take care about loading necessary plugins.
4.2 at project startup: project has it's own setting for a profile and kdevelop will unload disabled global 
plugins for the profile and load enabled global plugins for the profile;
project loader will load only plugins in profile;
_additionally_: signals unloadedProfile(name) and loadedProfile(name) would be emitted

5. How to deal with plugins which need to react to the profile change
- application wizard (limit the number of app templates in the list)
- documentation plugin (limit the number of doc plugins loaded and/or limit a number of documentation catalog)
- etc.

Solution: plugin will react on unloadedProfile(name) and loadedProfile(name) and perform necessary operations