+1, that all makes sense to me, and sounds like a Good Thing.
R
On Jul 15, 2011 4:27, Aaron J. Seigo <ase...@kde.org> wrote:
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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
