Plasma Plugin Loading

Marco Martin notmart at gmail.com
Tue Sep 2 08:22:07 UTC 2014


On Tuesday 02 September 2014, Sebastian Kügler wrote:
> That means we can use a mechanism similar to the Qt one to query plugins
> and then load them, KService would be out of the picture, so would ksycoca
> be -- we can use the query language parser without KService.
> KPluginTrader::applyConstraints(KPluginInfo::List &list, QString
> constraints) is indeed public API. That's the the really complex piece of
> code. The rest is basically looking up files in a bunch of directories.
> 
> The upside is that we can then remove the separately installed .desktop
> files in the services directories, and packages would be entirely
> standalone, no ksycoca runs necessary anymore, installing a package is

only thing, could this ever be reasonably fast? to me tis reminds me an old 
discussion about having a lot of little separate caches instead of the only 
big central sycoca..

> simply a matter of unzipping it into the right package directory, removing
> it also becomes easier, and we have less problems with stale or outdated
> service files around. Regarding the packages and plugins itself, this is a
> fully transparent change. It also means that plasmapkg can be cut down a
> bit, likely more cleanups can be done in other places. Also, less
> deprecation warnings.
> 
> I think my brain is empty now. :)

Thanks a lot for clarifying, i'm trying now to assimilate the informations :)

maybe would be useful to put those informations in the wiki as well? just to 
have a good recap what piece uses what plugin loading mechanism, why and what 
the plans are.

-- 
Marco Martin


More information about the Plasma-devel mailing list