The Plugin Problem (was KDevelop UI cleanup initiative)

[Sascha Cunz]

On Sunday 30 May 2004 20:34, Jens Dagerbo wrote:
> 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... ;)

Okay, compared to the effort it will take after 3.1, what i am talking about 
here is rather simple and could as well be done for 3.1 in time. But as i 
think, that it is more important for me to get appwizard done now, i should 
consider that _i cannot_ start too big changed _now_.

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

I try to avoid that as good as i can. The reason for that is clearly: If we 
had gone an XML way to represent the project creation, then this would be a 
simple fix. I'd simple move the Project-Template-DOM into the appwizard- 
template-DOM. ( template for .kdevelop as a subtag in .kdevtemplate ).

But we'll have to stick now with that endless .kdevtemplate files.

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

> "cppsupport is not a user-selectable plugin"
what if i choose to select cppsupport as secondary language and switch to it? 
It is selectable, it's just dumb to do it and i doubt it will be useful in 
any way. But hey, our GUI makes it posible.

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

Yeah, i see. As 60% of them are still broken, this is actually a point.

[even larger 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...) :)

Okay, so let me try to go to the basement again:
Fact is ( and i think we agree on that ), we can now code to modify the DOM at 
project creation time; but there should be a better solution in time.

Sascha