[Kst] Dummy objects and KstBasicPlugin
treat at kde.org
Thu Oct 5 23:11:40 CEST 2006
Currently the pluginify branch uses KDE 3.4's componentFactory for
instantiating and loading KstDataObject plugins. This is opposed to how
KstDataSource plugins are loaded with kst explicitly handling the symbol
lookup and loading.
Right now, in the pluginify branch we have the case that every KstDataObject
plugin has a shadow dummy object for plugin introspection and for providing
the config widget. This is nice for a couple of reasons:
1. It allows KstBasicPlugin to have a very basic API where only one magical
macro is needed to tell the KParts::ComponentFactory how to instantiate the
2. The plugin writer doesn't need to export an C symbols at all... the
implementation that a plugin writer needs to worry themselves about is
exactly defined by the use of some pure virtual functions in KstBasicPlugin.
3. It makes it much easier to deal with the configuration widget which can
just be called from the instantiated shadow dummy object. When a config
widget is requested, it has two modes: 'Edit' and 'New' ... in 'New' mode it
is expected to instantiate a plugin and load it upon the user clicking 'ok'.
In 'Edit' mode it must load a currently existing plugin object and adapt its
UI accordingly. This is very easy when you have a shadow copy, because the
impl for 'Edit' and 'New' is the same... either way you are adapting the
dialog's UI to one type of object.
4. With a shadow copy there is no need for additional .desktop property items
to distinguish between the various KstDataObject plugins. Without a shadow,
OTOH, creating a shadow dummy object has performance implications if the
plugin author decides to do anything resource intensive in the plugins
Right now, I'm having a hard time getting rid of the shadow dummy object
without entirely changing the API for KstBasicPlugin.
In order to get rid of it, I'll have to do away with the virtual pure methods
in KstBasicPlugin and the plugin author will have to be responsible for
providing some static C methods that provide introspection of the plugins
various input/output objects as well as a static C method providing a config
Note, that even getting rid of a shadow dummy object ... we still need to
instantiate a 'plugininfo' object for each plugin that will take care of
checking for and calling into these various static C methods.
Personally, I think the cleaner solution is to just keep using the shadow
dummy plugin objects and putting some clear notices in the documentation that
resource intensive bits shouldn't be included in the ctor.
More information about the Kst