plugin plans

Sebastian Kügler sebas at kde.org
Wed Sep 25 09:48:50 UTC 2013


Hey,

As I've been working quite a lot on KService's plugin infra lately, I have 
some ideas about changes in Plasma.

Background: KPluginTrader is new API in KService. It can replace 
KServiceTypeTrader, and thus the need to separately install .desktop files for 
plugins. Feature-wise, it's very similar, i.e. we can still query plugins 
using the constraint syntax.


Plugin installation pathes

I'd like to install our binary plugins into subdirectories. This is in line 
with how we'll do it across KF5. These plugins won't need .desktop files 
installed anymore. For dataengines, this is the most advanced right now. I 
have a branch which makes Plasma::PluginLoader use KPluginTrader. Before 
merging this, however, I'd want to update you on the overall strategy and give 
the opportunity to chime in.

The first "victim" here will thus be dataengines.

Packages

The new API also allows us to use packages' metadata for querying. It means 
building up a KPluginInfo::List from metadata (so a bit of crawling through 
the filesystem, but probably not recursively, to list plugins. Looking at 
plasmapkg, the code to list packages is a bit convoluted right now, and I'd 
like to see that fixed. Plasma::PluginLoader should actually satisfy the needs 
of plasmapkg, without writing custom "look for packages"-code.

This means, for packages and dataengines, KSycoca isn't needed anymore.

With this in place, we can tackle more pieces of Plasma::PluginLoader to make 
it sycoca-free.

Obviously, this is your chance to weigh in. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Plasma-devel mailing list