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