The Plugin Problem (was KDevelop UI cleanup initiative)

[Jens Dagerbo]

Well.. this thread went haywire in no time.. We've ended up talking about 
different things. My only goal was a simple mechanism to avoid loading every 
available plugin that 
1) doesn't mean we have to change every individual template 
2) doesn't touch a lot of existing code so that we're reasonably confident it 
will be implementable of the coming few weeks before the feature freeze (and 
so will be in 3.1)

What you are talking about is How Everything Should Be(tm), but I doubt we can 
get that into 3.1... ;)

What I was imagining was this:
The appwizard sees a c++ project. It looks up what the default set of plugins 
for this project type should be and tells the project to load these. 
(Actually, come to think of it, this can be implemented on top of the current 
blacklist mechanism, which means very little code needs to be changed. We 
just need a way to modify the DOM before the project is loaded from it.)


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

Apart from the fact that the above example is bogus (cppsupport is not a 
user-selectable plugin, cppdebugger and valgrind can't reasonably be seen as 
_required_ plugins for any project I've seen), part of the whole idea was to 
avoid modifying the template .kdevelop files.


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

I didn't understand this response, but I don't think this has much to continue 
on anyway.

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

Hmm.. maybe I just confused the issue by starting to talk about default 
settings. That is a different problem from the one I set out to discuss.

Btw, here you discuss the FileCreate part.. which isn't an optional plugin 
either. We're clearly not discussing the same problem anymore.

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

Great! That was the end of that paragraph.. :)


[large snip]


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

Well.. good. This is the "event horizon" I wanted for this discusson to begin 
with. Long term I certainly agree tougher measures are needed (and of course, 
I have a few ideas as well...) :)


jd