Applet::load and friends ... or PluginLoader::load..

Aaron J. Seigo aseigo at kde.org
Fri Jul 15 13:26:45 CEST 2011


hi...

so, we have the PluginLoader class now which is there to allow extending the 
loading of plugins by the application.

there are methods like: PluginLoader::loadApplet and PluginLoader::loadPackage

these are generally only used by the internals of classes like Applet::load, 
which is currently this:

Applet *Applet::load(const QString &appletName, uint appletId, const 
QVariantList &args)
{
    return PluginLoader::pluginLoader()->loadApplet(appletName, appletId, 
args);
}

not much to it, is there? :)

this is the same for AbstractRunner::load, Package::load, and on and on ..

the one exception to this pattern is DataEngineManager, which does some 
internal bookkeeping around the PluginLoader method. that may be going away, 
however, in libplasma2 if we manage to get reference counted implicitly shared 
DataEngines.

anyways.. the thing i'm contemplating is this:

Removing all the "load(..)" methods from the classes, and instead have 
everything use PluginManager directly.

pros:
  * fewer methods in general in the API, particularly ones that plugin writers 
don't care about
  * it follows the pattern now done with Package which handles all package 
loading instead of per-class API for that (in fact, it goes one better: 
Package::load would also disappeaer)
  * consistent way for loading plugins: use PluginLoader

cons:
  * code like Applet::load becomes PluginLoader::self()->loadApplet. in other 
words, rather more verbose. i could change PluginLoader to instead of "having 
loadApplet" or "loadDataEngine" just "applet" and "dataEngine"

thoughts?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110715/0349a660/attachment.sig 


More information about the Plasma-devel mailing list