[Kst] Dummy objects and KstBasicPlugin

[Adam Treat]

On Monday 09 October 2006 7:44 pm, Barth Netterfield wrote:
> 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.

Well, as an alternative, if a plugin needs to do resource intensive bits it 
can do them in an init() function triggered from the algorithm method.  The 
plugin infrastructure will construct the plugin on startup, but this won't 
touch the critical 'algorithm()' method until the plugin is actually _used_.

> -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).

Yes, with a shadow dummy object they are instantiated on startup... all of 
them.  

However, I fail to see how this is any more of a performance hit than 
constructing a PluginInfo object like the datasources already do.  Either way 
you are loading the library of the plugin, calling methods, and instantiating 
a PluginInfo object for every plugin on startup.

I think if we tell the plugin authors to use an init() function triggered from 
the algorithm method rather than putting resource intensive bits in the ctor 
we'll be just fine and the API will be much nicer.

Adam