The Plugin Problem (was KDevelop UI cleanup initiative)

[Sascha Cunz]

On Sunday 30 May 2004 13:51, Jens Dagerbo wrote:
> > > 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.

I already wanted to do that - but it was late in the morning :)

>
> > 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)?

If we got a white-list, this whitelist could contain "ctags". Now, that we are 
about to deprecate ctags and use ctags2 instead, we could create a stub 
"ctags" plugin, that will do nothing more than change ctags to ctags2 in DOM 
and then terminate. OTOH, if we did check the whitelist for sainity, we could 
have a "ctags2 obsoletes ctags" entry in our list, and change ctags to ctags2 
without loading anything. Just one example; there are much better ones, if we 
consider dependencies to become real.

> > 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.
Yes.

> 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.
that can be simply done by putting a good blacklist into the template's 
default DOM.

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

We currently have to (re-)implement appwizard loading the project after 
creation. Maybe we can go a better way:

- Make the app.kdevelop file in each template as lean as posible.
- Add a virtual method: KDevPlugin::initializeProjectDom(QDomDocument&);
- From appwizard: enumerate all plugins that will be used, and call 
initializeProjectDom for that plugin. Note that it is unimportant how we 
assemble that list of will-be-used plugins.

This way, we could sanely omit the necessity to fight with XML Changes in 
appwizard. I think Ian will love this :)

With this approach, we could also:
- Let a plugin write it's default configuration to the project DOM, when it is 
aded to the whitelist after project creation.
- Change default configuration of plugins in the plugin, not in the project 
templates.
- Posibly this is also required for on-the-fly migration from a black list to 
a white list.

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

Why?

> > 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.. ;)

And acutally i start thinking, most of this stuff has to wait for kdevelop 3.2 
or kdevelop 4; we're just too near to the release cycle. (At that point, i 
wonder why people willing to contribute always popup when time is near to a 
release)

Further, as we're planning to include workspace support in kdevelop at any 
time, we should really take this into consideration - at least we should keep 
one eye on it. This is just because implementing workspaces has to do with 
activating/deactivating plugins depending on the current context and 
loading/unloading plugins as necessary.

Cheers
Sascha