Profiles and "disabled plugins"

[Jens Dagerbo]

On Saturday 21 October 2006 07:57, Vladimir Prus wrote:
> On Saturday 21 October 2006 01:42, Jens Dagerbo wrote:
> > On Friday 20 October 2006 20:14, Vladimir Prus wrote:
> > > Hi,
> > > for quite some time, it was possible to specify a set of disabled
> > > plugins for a given KDevelop profile. This no longer works in SVN head.
> > > This was changed in revision r525148, by Jens. Log message was:
> > >
> > >      r525148 | dagerbo | 2006-04-01 02:46:23 +0400 (Sat, 01 Apr 2006) |
> > > 1 line
> > >
> > >      Use Alexander Dymo's ProfileEngine to specify the default plugin
> > > set for a freshly created or imported project
> > >
> > > and the actual diff is attached. The only functional change is
> > > commenting out the code that handles disabled plugins, with comment
> > > that says:
> > >
> > >        /* Wrong, this is not what we want to do.
> > >
> > >
> > > Jens, can you tell what was wrong with original behaviour,
> >
> > There was nothing wrong with the original behaviour (except maybe that it
> > was somewhat redundant) UNTIL people started using the disable list to
> > "clean up the ui" which wasn't at all what it was designed to do.
> >
> > The enable list tells Develop that a plugin CAN be loaded.
> > The disable list _told_ KDevelop that a plugin CANNOT be loaded.
> >
> > In effect a disabled plugin was blocked and for all practical purposes
> > did not exist (for that profile). Using this system  to "clean up the
> > ui"meant you limited what parts of KDevelop the user was allowed to use
> > by your preference of what was nice to see in the UI.
>
> If "disabled plugin" functionality permanently disabled some plugins from
> being used, and that's not desirable, 

> would a reasonable fix be to change 
> the semantics of "disabled plugin" -- so that it not available initially,
> but still can be explicitly disabled by the user?

This what I did  and this should already work. See 
AppWizardDialog::openAfterGeneration() - we read the disable list and add it 
to the 'ignoreparts' list set by the template.

Note that this list is only applied on project creation. After that, the 
_user's preference_ is all that matters.

> As it stands now, we have "dead" functionality in the plugin engine and in
> kdevprofileeditor as well.

Incorrect, as I explained above.


> > The current behaviour is, imho, the better way. And at least back in
> > april, when I changed the behaviour, Alexander Dymo agreed with me. I
> > hope he still does. :)
> >
> > > and what's  required in order to revive the disabled plugins
> > > functionality?
> >
> > As a project template writer, to impose your preference as to what should
> > be loaded by default - use the "<ignoreparts>" section of the
> > template's .kdevelop file.
>
> I have more than one template that uses the same profile. Duplicating the
> list of disabled plugins in each seems quite inconvenient. 

Agreed. (And so is the fact that a new template needs to be "registered" in 
the profile!) We should change this in KDev4. KDev3 always had the approach 
"let's load everything". Let's not make this mistake in KDev4.


> What's worse -- 
> if you already have project created with certain profile, when you upgrade
> to current version of KDevelop, all disabled plugins will magically appear.

As a consequence of KDevelop3's "let's load it all" approach, yes. It's only a 
half dozen click for the poor user to correct it by unloading them though. 
And maybe she/he found some new plugins she/he liked in the process. I can't 
say I think this is serious issue.


> Having two debugger plugins show up is not very nice ;-)

As far as I know, the debugger plugin needs to have changed name for this to 
be possible. Has it? Can you in fact make it load twice??


// jens