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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
