kross plugins

Andreas Pakulat apaku at gmx.de
Mon Nov 24 12:30:10 UTC 2008


On 24.11.08 12:51:24, Aleix wrote:
> what's wrong about how Kross plugins are loaded?

The problem is that we currently simply load all plugins by default (except
project plugins, but that might change sooner or later). Which means
kdevkrossplugin.desktop gets read and is being loaded as well. Except that
this plugin is not meant to be loaded that way, instead its meant to be
loaded via another .desktop file which has a X-KDevelop-PluginType of
"Kross". The reason is simply that the plugin expects a name+interface in
its argument list and asserts() if there's none.

One way to "fix" this for now would be starting to list all plugins in
kdevplatform+kdevelop which are "Global" in kdevideextension.cpp for the
defaultPlugins() method. And leave kdevkross out of that, then it won't be
loaded on start. Same thing would need to happen for the Autotestshell
(thats what broke when I removed the profile system).

Another would be special-casing the plugin loading for a plugin with the
ide "KDevKrossManager". 

I don't really like either of the two, both seem to be kind of a
workaround. Ideally I'd like to have no installed plugin that serves as a
proxy for script-plugins. Instead have a kross-manager class inside shell/
that directly creates Plugin instances and KPluginInfo and injects them
into the plugincontroller (no api there yet, but that wouldn't be a problem
to add).

The only point where this could be a problem is with the extension
interfaces, because I'm not sure those allow to add an interface during
runtime (I'm not sure though).

What do you think? We can of course also just gor for option 2
(special-casing KDevKrossManager) for now and re-evaluate option 3 at a
later point (seeing that we lack resources and option 3 might need quite
some work).

Andreas
 
-- 
You will obey or molten silver will be poured into your ears.




More information about the KDevelop-devel mailing list