The Plugin Problem (was KDevelop UI cleanup initiative)
jens.dagerbo at swipnet.se
Tue Jun 1 14:48:30 UTC 2004
> > 1. The default loading of all plugins.
> > A new users first start of KDevelop with a C++ project loaded will have
> > every available plugin under the sun loaded, including four VCS plugins
> > and support for Gameboy development. It's hard to fault his/her feeling
> > that KDevelop is "bloated", even if he/she is wrong.. ;)
> > This particular problem could hopefully be fixed with a little less
> > enthusiastic loading of plugins, something I'm working on.
> Woo, you kicked that objective public. I bet you're gonna have a discussion
> of similar size that was raised related to template changes. - And i'm
> gonna start with a few of the things we talked about in irc during the last
> half year:
Maybe you're right.. To not mix this discussion with the plain UI cleanup I
split this off into a different thread.
> 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
> Creating such a list would involve changing the DOM at project creation
> time - A thing we currently do not support. Though, it might be fun to have
AFAICT, it is absolutely neccessary for the Plugin Profiles idea I was toying
with to be implementable.
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
The basic idea was:
# The template .kdevelop file contains a whitelist. This is the list of
plugins it "needs" to load. Presumably these are more or less the same
plugins that have predefined settings in the .kdevelop file already.
# A list of profiles define what plugin set makes sense for a particular kind
of project. This is not a large list. I'm imagining some 3-4 profiles would
# The profiles should be modifiable by the user, new profiles createable and a
default profile selectable per project type. At least the selecting of a
profile needs to be doable from the appwizard.
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
> With this approach, we could be a big step closed to have support for
> downloadable plugins. But i think there has to be a few things to be done
> before that.
Indeed there will.. ;)
More information about the KDevelop-devel