The Plugin Problem (was KDevelop UI cleanup initiative)

[Jens Dagerbo]

> > 1. The default loading of all plugins.
> >
> >  A new users first start of KDevelop with a C++ project loaded will have
> > every available plugin under the sun loaded, including four VCS plugins
> > and support for Gameboy development. It's hard to fault his/her feeling
> > that KDevelop is "bloated", even if he/she is wrong.. ;)
> >
> > This particular problem could hopefully be fixed with a little less
> > enthusiastic loading of plugins, something I'm working on.
>
> Woo, you kicked that objective public. I bet you're gonna have a discussion
> of similar size that was raised related to template changes. - And i'm
> gonna start with a few of the things we talked about in irc during the last
> half year:

Maybe you're right.. To not mix this discussion with the plain UI cleanup I 
split this off into a different thread.

[snip]

> I think we all agree that the approach of a "bad-list" is not what we
> really want to have. So we should turn that into a "good-list", which
> contains a list of plugins being loaded with the project.

Yes, our current "blacklist approach" should be changed to a "whitelist". This 
is what I want. A project templated .kdevelop file already contains settings 
for some plugins. It then decides what plugins to load by saying what plugins 
it doesn't want loaded. This is clearly not designed with a rising amount of 
available plugins in mind.

> This list would have to be checked against the available plugins at project
> loading (to see if it is actually still a sane configuration)

I'm not sure I understand why. If I, in the template, select exactly the 
plugins I need, isn't it sane to expect I know what these do (and that they 
will work)?

> Creating such a list would involve changing the DOM at project creation
> time - A thing we currently do not support. Though, it might be fun to have
> :)

AFAICT, it is absolutely neccessary for the Plugin Profiles idea I was toying 
with to be implementable.

Note: The only problem I propose to solve is the lack of a sane default set of 
plugins loaded at first creation of a project. Profiles would not come into 
play after that, the plugin set is then fully decided by the .kdevelop file 
as usual.

The basic idea was:

# The template .kdevelop file contains a whitelist. This is the list of 
plugins it "needs" to load. Presumably these are more or less the same 
plugins that have predefined settings in the .kdevelop file already. 

# A list of profiles define what plugin set makes sense for a particular kind 
of project. This is not a large list. I'm imagining some 3-4 profiles would 
be enough. 

# The profiles should be modifiable by the user, new profiles createable and a 
default profile selectable per project type. At least the selecting of a 
profile needs to be doable from the appwizard.

To not change the code too much, we could keep the current mechanism where 
the .kdevelop file keeps a blacklist (what not to load) and rely on that once 
the project has been loaded once and an up to date blacklist created. The 
only immediate downside to this is that a new plugin, installed after the 
project is created, will automatically be loaded, but that's not that big a 
deal, imho.

> With this approach, we could be a big step closed to have support for
> downloadable plugins. But i think there has to be a few things to be done
> before that.

Indeed there will.. ;)


jd