[Kde-imaging] kdeextragear-libs-1/kipi-plugins [POSSIBLY UNSAFE]

[Jesper K. Pedersen]

On Sunday 02 May 2004 20:13, Aurelien Gateau wrote:
| Le dimanche 2 Mai 2004 19:38, vous avez écrit :
| > What we are developing here is pretty unique, so there will always be
| > some edges.
| >
| > We have two possibilities:
| > 1) We can ensure that kipi only contains a subset of features that any
| > host app can accept, and as the number of host apps grows, this number
| > will approach zero.
| >
| > 2) We can give the plugins/host apps the possibility to say I dont like
| > that plugin or I dont like that host app.
| > The comments editor was one, slides shows, and html generation are other
| > possibilities.
|
| If I remember well what Renchi told on IRC, the comment editor plugin is
| supposed to be integrated directly inside Digikam and will no longer be a
| plugin.
Well the situation will show up again with other plugins I'm sure.

|
| > Lets be realistic we are not seeing thousands of plugsins, and I think
| > you have to distinguish between plugins that the user downloads himself
| > and plugins which are in kipi-plugins.
|
| No. XMMS has hundreds of plugins. It does not make a distinction between
| default and third-party plugins.
I'm not sure what XMMS is. But if its just one application, then thats what is 
different for us, we have a bunch of pretty different apps which each have 
certain strong sides, and which will not gain anything from certain plugins.

|
| > Plugins the user downloads himself from the net can host apps not do
| > anything about - how should it know about these - on the other hand. If
| > the user downloads them, then he knows explicit about it.
| >
| > | Aurélien, currently wondering if KIPI is such a good thing after all
| >
| > Why is that?
|
| Same thing as always: just look at the Digikam plugin list. Can you name
| one of them which could not be implemented as a separate binary? What do we
| really gain with plugins?
| I see only one thing: getting the plugin to automatically appear in the app
| menu. This could be achieved with little pain with binaries.
| On the other hand, plugins force you to extend your application in C++: one
| can't easily write plugins in Python, Perl, Ruby or whatever easier
| language.
Well you would then have to have a lot of communication with the app, I mean 
the host app and the plugin-app would need to communicate about changes in 
selection etc - thats gotta be really ugly.

|
| > Let me put it this way - I'd be very very very unhappy about having
| > duplicate features from plugins, which would just make my app harder to
| > use, so I really need the possibility to deny certain plugins.
|
| The comment editor is a bad example since it's supposed to be integrated
| back into Digikam. I believe other features can be implemented as plugins.
| For example your app could provide a simple slideshow plugin, then let the
| user select which slideshow plugin he prefers.
Well it happens that KimDaBa has a pretty powerfull slideshow feature, which 
supports the categorization which is KimDaBa's strong side, so even a good 
slide show plugin would likely not be worth it for kimdaba users.

And I for one would rather not have it available by default then - My target 
audience includes in the long run (at least for viewing) your grandma who 
hardly know what a computer is - dunplicate functionality will for sure just 
confuse her.

But having said that my plan is to develop (in libkipi) a plugin chooser that 
can be integrated into the host app to configure which plugins should be used 
at all, and in that case the disabling I'm talking about will merely be a 
hint then (and a default) 

Still, remember the uglyness you fight against here is in the host app, not in 
the plugins, so if you dislike it, just pass an empty QStringList, and you 
will never see uglyness. I'll personally monitor plugins closely and choose 
which will be good for KimDaBa, and which will confuse users more than they 
will do good.

Cheers
Jesper