[Kst] Dummy objects and KstBasicPlugin

[George Staikos]

Couldn't we put two classes inside the plugin?  One that provides the actual 
plugin, and one that provides information about the plugin and possibly the 
dialog and other such things?  That second class could of course be 
instantiated on load.

I'm concerned about plugin writers when we instantiate "shadow objects" 
because it's just not clear that the object can have two modes.  I'd really 
like to see an alternative.

On Thursday 05 October 2006 17:11, Adam Treat wrote:
> Hi all,
>
> 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 plugin.
>
> 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, there is.
>
> OTOH, creating a shadow dummy object has performance implications if the
> plugin author decides to do anything resource intensive in the plugins
> constructor.
>
> 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 widget.
>
> 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.
>
> Thoughts?
>
> Adam
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/