The Plugin Problem (was KDevelop UI cleanup initiative)

[Jens Dagerbo]

I disagree. ;)

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

Hmm.. this is a good point, but it is not solvable. If a template truly 
_depends_ on a nonavailable plugin, that's just tough. We can't reasonably 
have a concept of "plugin compatibility" and there is very few cases where 
this is even thinkable anyway. This is not a real problem. It does not need 
solving.

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

So far, I remain unconvinced. I have yet to see a need for this.


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

Not really. This is what we have now, and that breaks as soon as someone adds  
a plugin. (Someone adds a specialized plugin (think GameboyAdvance) and bugs 
the hell out of everybody, as this will again be loaded for new project.) Do 
you suggest every template should be updated when this happens? I must have 
misunderstood something..


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

HUH!? You are suggesting a plugin should be instantiated to write its own 
defaults into the DOM? This could be done with far less trickery... isn't it 
in fact automatic? If a plugin can't find any settings in the project DOM, it 
will use its defaults. How is this different?

What it doesn't solve is the possible need to feed the plugin with project 
type specific settings. These needs to be in the project template .kdevelop 
file.


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

Why what?

Why not change the code "too much"? 
I would guess that selfevident.. ;)

Why does the blacklist approach work once the project has been loaded once? 
Because once loaded, the project will know what plugins it has loaded and what 
plugins are available. The diff is the blacklist. 

The blacklist approach is quite wired into the ProjectManager <-> 
PluginController interaction, and would probably be unwise to change at this 
stage.


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

Well.. you're the one that wants to complicate things ;)


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

Yes, this is a very good point. I'm not sure what "deactivation" would do in 
your mind, but one slightly annoying things we're currently doing is 
unloading and loading the same plugins when we're switching project. On the 
up side, we know they will be "clean". :)


jd