[Kde-imaging] Selecting images for plugins

[Jesper K. Pedersen]

On Monday 28 June 2004 15:59, Renchi Raju wrote:
| On Mon, 28 Jun 2004, Jesper K. Pedersen wrote:
| > On Monday 28 June 2004 14:13, Aurélien Gâteau wrote:
| > | If we agree on having libkipi (not the host app) supply a widget for
| > | album selection (I'll call it KIPI::AlbumSelector for now), then we can
| > | have an AlbumSelector::images() method for plugins which needs it. The
| > | current* methods should only be used by dialog-less plugins.
| > | As far as I'm concerned, I think the current* methods are ok. Plugins
| > | which modify the images should use currentSelection() only, plugins
| > | which only read images should use either one of the three methods.
| > | I don't see a need for it being virtual now, but it should not imply
| > | any performance cost, so I'm ok to have it virtual if you need.
| >
| > Well I'm afraid is it not as easy as that.
| > As I said earlier in this thread, I prefer the way things are now, but
| > could accept the selection widget, if it was not too much trouble for the
| > plugins, and if it was forced upon the plugin deevloper (if not forced
| > upon plugins, we would not gain anything from this change, which was our
| > starting point)
| >
| > Second, having the host app supply a widget, will not make it possible
| > for me to get back to the original setup (as it is now). The reason is
| > that in a widget() method I would not be able to know if I should return
| > a widget (which would be the case for plugins that currently uses a
| > widget), or if I should return nothing (which is the case for those
| > widgets, that currently uses no widget).
|
| the widget is requested only by plugins which require an album selection.
| plugins working with current* do not request an album selector widget (may
| it be from kipi or from the host app)
Well this is what Aurelien want to change.