[Kst] Dummy objects and KstBasicPlugin

[Barth Netterfield]

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.

We had decided about 18 months ago to bump to 3.4, but never actually got 
driven to it.... so, it is fine with me if we bump to 3.4.

> 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?

-This has never actually been an issue, but, if the author does need to do 
some serious work (pre-caching calculations, or reading config files, etc) 
that would normally go in the constructor, is there a way of hinting to the 
shadow object that it doesn't need to do them?  Alternatively: IFAIK, with 
the C plugins, people have done this kind of stuff with a static first_time 
variable in the plugin where the calculations are done and returned.

-Do all of the dialogs get built when kst starts, or do the get built when 
needed (relevent for startup performance if you have hundreds of plugins).