[Kde-imaging] Selecting images for plugins

[Jesper K. Pedersen]

On Thursday 24 June 2004 17:42, Renchi Raju wrote:
| 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).
May I conclude that you state that what we currently have is just fine (modulo 
the currentScope)?
If so, then I agree with you, personally I have no need for changing things as 
they are now.

Could we agree on the currentScope() function being virtual, so KimDaBa could 
reimplement it to its current value, with the default being to return the 
selection?
Still keeping currentSelection and currentAlbum in case som plugin wanted to 
do something specific.

|
| > | 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.
See now I'm not sure what you are talking about.
Which widget are we talking about here?

| > | > 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?