[Kde-imaging] Selecting images for plugins

[Renchi Raju]

On Thu, 24 Jun 2004, Jesper K. Pedersen wrote:

> On Thursday 24 June 2004 16:54, Renchi Raju wrote:
> | ok, some preamble before anymore discussions. i think we are mixing up two
> | different issues and its best that we handle these separately:
> |
> | a) currentAlbum/currentSelection/currentScope:
> |
> | there are plugins which act on individual images or a set of individual
> | images directly, eg: slideshow, print, rotation.... these plugins take
> | what is given by the app through either selection or all the images in the
> | current view (usually a thumbnail view) in the app. its best not to have
> | further interaction from the user for these plugins: user selects images,
> | clicks the print action and the selected images are set for printing.
> | usually such plugins act only on the selection (and in some cases, like
> | printing and rotation, should act only on the selection). some plugins
> | (like the slideshow) can also query the user as to which images to use,
> | selected ones or all of them in the current view.
> |
> | b) all albums:
> |
> | these are plugins which need set of images from the app to act on.
> | examples: cdarchiving/imagegallery. these plugins don't want individual
> | image urls. they want a list of imagecollections/albums (which
> | individualy are a collection of image urls). it would be nice for these
> | plugins to get all the albums (if possible and allowed by the host) in the
> | app, so that user can select which albums need to handled. these plugins
> | don't have anything to do with current selection or current view. for such
> | plugins further user interaction is necessary (using a selection dialog).
>
> First of all, I'm perfectly OK with the above, and this is what is in KIPI
> currently, modulo discussion of currentScope(), which you want changed back
> to currentSelection(), which is OK with me. It would be inconsistent with
> KimDaBa, but a solution to that problem could be to make it a virtual method
> default implemented to currentSelection(), and KimDaBa could override it to
> return current view when no selection are made.
>
> Next, are there really a reason for this split up?
> Are there any reason why I should not be able to browse to a set of images,
> select them, and burn them to cd? With the suggestion in this mail thread the
> user can choose what he want (a number of albums and/or selection)

also answering to your question at the bottom: the reason for this "split
up" is that lot of plugins work best on current selection and/or current
view. for eg, rotation: user selects an item and then chooses to rotate
it. it would be rare usage for an user to start the rotation plugin and
then browse/search for images to rotate. in such cases, the plugins act
like mini-apps; the selection/collection should be handled by the host
app. i would say that user should not be made to do further interaction
for such actions by the app/plugin.

maybe i was too strict about this broad classification of plugins. there
is nothing which prevents a plugin from allowing further
interaction/selection from the user. for eg, the slideshow plugin in
addition to the current selection and current view could also provide a
third option to select more images by browsing through the albums. for
easier usage, this third option should not be the default (as being
suggested by you). but then again, its always upto the plugin to decide
what would work best.

my point is that: give exactly what the plugin requests. if the plugin
requests current selection - provide current selection, if it requests all
albums - provide all albums. that is why there are three functions to
interact with the app: currentSelection, currentAlbum, allAlbums. there is
no separate interface for plugins (a) or (b).


> | from what i understand, for plugins of category (b), where this issue of
> | album selection arises, currentalbum doesn't have to be a part of all
> | albums. if the app chooses to, they can add the current album to the list
> | of all albums, but in digikam for eg, we won't be doing that, as the
> | current album is naturally a part of all albums. in kimdaba, you are not
> | required to add the current album to all albums.
> Right, my point simply was that there would be none of the albums from
> allAlbums() that you select, so rather than being without a selection, I
> would prefer if all albums was selected, and I guess you would prefer if the
> current album was selected.

i'm not sure i understand what you are trying to say. are you saying
that in the album selection widget provided by the app, all albums or
current album should be selected? if that is so, then its the app which
provides this widget and its upto the app to select whatever it wants.

> | > I guess you forgot "current selecttion   3 images" in the above didn't
> | > you? If not, how would I execute a command on the selection?
> |
> | the current selection make sense only for plugins of category (a) and for
> | such plugins (imo) shouldn't have a dialog of 'all albums'.
> To make us ever come to a conclusion here, let me state Aureliens argument (as
> I understand it), given he wont be able to answer before Monday.
> Why do we need a different interface for (a) and (b)? Wouldn't it be better to
> have the same interface for all kinds of plugins?
>
> Is there anything that really prevent me from selecting a number of albums for
> a slide show?