[Kst] Dummy objects and KstBasicPlugin

[Adam Treat]

Barth, George?  Thoughts?

On Thursday 05 October 2006 5:11 pm, 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