The Plugin Problem (was KDevelop UI cleanup initiative)

[Sascha Cunz]

On Sunday 30 May 2004 16:13, Jens Dagerbo wrote:
> I disagree. ;)
So here it becomes complex ;)

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

As for the templates, this could actually be _very_ simple. Let's just add 
"requiresPlugins=cppsupport,cppdebugger,valgrind,..." and we're done. This 
could be template dependant and is IMHO more sane than the whole 
profile-solution.

> > 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.
I won't try to convince you either. But consider comments at the very end of 
this mail.

> > > 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..
no, and i was acutally referring to the way it currently is.

> > 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?
hm, not exactly what i meant. What i mean is, that we need to load the plugin 
anyway. Tell it at that time simply to do the default initialization. This 
would be exactly the things that are currently done in apptemplates. i.e. 
this would be: activate a set of createable files for the file_create part; 
depending on what type of language the new project uses. But maybe this 
should still be in the project template.

> 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?
So far, i think you're right with that paragraph.

> 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.. ;)
Because it often happens to be just doing a few things more, to get to the 
"right" solution. Yeah, i know that i am in a very minority position here. 
But i did not do almost 10 years of comercial software development (5 of 
which i was selfemployed ) to ignore all the things i learned. Thinking a 
reasonable time slice ahead is most of the time neccessary to avoid doing 
stuff twice. Note, that i do not talk of implementing it the right way from 
beginning on; just "think ahead" and choose an easy to migrate way.

> 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.
Of course this is true for the default user, who works with the same version 
over some time. But as soon as the user is able to update to a kdevelop 
version with more plugins - or has the ability to install other plugins 
without ease - this system gets broken, because you are back to the point 
where a plugin is loaded regardless what is in the blacklist.

Well, we have a project tempalte to create a kdevelop plugin outside the 
source tree of kdevelop. And i know that i've talked to at least one user who 
actually has done that. So if anybody installes this plugin; all projects he 
opens will load that plugin.

We should ditch the Blacklist ASAP. It will get us into trouble the more we 
extend kdevelop - or allow 3rd parties to extend kdevelop.

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

I agree to "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 ;)
Not without a reason, usually.

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

Shouldn't be "cleanup a plugin on projectClosed() slot" be at a higher 
priority then?
For workspaces to work, we need a bunch of things that we are currently 
lacking. One of this is: reusing language plugins for more than one project - 
or load it several times.

Sascha