[Kde-imaging] Image plugins question

[Renchi Raju]

On Wed, 12 Jan 2005, ian geiser wrote:

> I recently added wrote an application that uses the libkipi plugins.  I had a
> few observations and would like to start a dialog so that the libkipi
> interface for host applications can become less painful.

i wasn't aware that host app interface for libkipi is too difficult. A 
quick check on gwenview src code indicates it needs around 176 lines of 
code (including header/comments/copyright) to implement the interface.

> The first observation is that there is quite a bit of code to do simple
> things.  I have not written a plugin, but I was told this was so plugins are
> easier to write.

from what i can see, there is no fluff in the code. but we will be happy 
to fix it, if you can point it out.

> One thing I did notice was for the enormous amount of code
> that was needed to use libkipi in the host application there where no ways to
> do the following:
> 1) configure the plugin via the host applications gui
> 2) control options in the plugin via the host application
>  example: I have scripting support in my application but
>   there is no way to set properties in the plugin and execute
>   the plugins action.
>
> Now 1 is pretty simple, we can just export a QWidget that the host
> application can null check, and if its a valid pointer, slide it into the
> main config dialog.

this is certainly possible. but the question is whether there is a need to 
do it. The host app configs are usually quite full and this might add to 
the clutter. Additionally, there might be a strong reason for the config 
of the plugin to be in quick reach of the plugin's gui. Most (all?) of the 
plugin dialogs are modal and it might not be desirable to close an 
existing dialog to edit the config. For eg, if you are generating an html 
page, from the imagegalleryexport plugin, its best to have the config for 
setting the background color, number of thumbnails per page within easy 
reach.

> 2 is a bit more complicated.  Historicly most
> applications (in Win32 and MacOS classic land) would use a "property map" to
> set properties in the plugin, and then an "execute" method to tell the plugin
> what to do.  Personally I find this a bit inflexible because you don't get
> nice things like validation, or more complex operations on a plugin.  One
> option I am leaning towards is DCOP.   DCOP has some advantages here when
> used in a plugin.  When DCOP is used in process you do not have to go through
> the server, this means less overhead.  It also allows more complex
> functionality without resorting to direct linkage.  The drawback of DCOP is
> that there is no real good way to enforce a uniform interface.  In my case
> this is not a show stopper since scripts are accessing the plugins via
> KScriptInterface.

I'm not quite certain i understand you completely here. the kipi-plugins 
use a pull method rather than a push method, where when it needs an 
option, it accesses it using the existing methods in the interface (and 
possibly the attributes map... this sounds similar to the "property map" 
you mentioned). The "execute" method sounds similar to the executing of 
(k)actions from the plugins embedded in the host app menus/toolbar. Or 
maybe i'm off the track completely and an example with details will 
enlighten me.

regards,
renchi