[Kst] Dummy objects and KstBasicPlugin

[Adam Treat]

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