[Kde-imaging] Selecting images for plugins

[Jesper K. Pedersen]

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)

In any case plugins can't anymore make any assumption about "album == dir", so 
they will have to work on a set of images, and whether that set comes from a 
selection or a virtual album should not make much of a difference to the 
plugin.


| now that this is off my head, let me try and reply to your mail.
|
| On Thu, 24 Jun 2004, Jesper K. Pedersen wrote:
| > On Thursday 24 June 2004 16:02, Aurélien Gâteau wrote:
| > | Le jeudi 24 Juin 2004 14:15, Jesper K. Pedersen a écrit :
| > | > <Aureliens suggestion as Jesper understands it>
| > | > - current selection
| > | > - album1
| > | > - album2
| > | > ...
| > | > with the current album being selected.
| > | > </Aureliens suggestion as Jesper understands it>
| > | >
| > | > I'm not really thrilled about this, I really like the current setup,
| > | > but it seems like neither Renchi nor Aurelien likes that, so I have a
| > | > few suggestion for changes, and to make every one happy I give in
| > | > this time.
| > | >
| > | > <Read-only-section-no-need-to-comment>
| > | > Here is my problem with this suggestion:
| > | > KimDaBa do not have the concept of albums at all, therefore when a
| > | > plugin asks for an album, I have to make something up.
| > | >
| > | > For current album I return the current scope (which is those images
| > | > that you currently have browsed to, e.g. "all images of Jesper with
| > | > beers".
|
| that is correct. other apps like digikam and gwenview also handle it this.
| current album is current set of images which have been browsed too.
|
| > | > As I don't have the concept for current album, I dont have the
| > | > concept for all albums naturally, and it is pretty hard to extend my
| > | > definition above from current album, to give a definition that spells
| > | > sum( all possible current albums ) == all albums
| > | >
| > | > The above definition is the basis of Aureliens suggestion in the
| > | > first place, namely to show all albums side by side, and open the
| > | > current one.
| > | >
| > | > Now how do I implement all albums?
| > | > I implement this by using say the "Keywords" to make sub albums,
| > | > those if you look at http://dotfile.adsl.dk/dump/img1.jpg I would
| > | > have albums labeled "No Keywords", "Anne Helene's ..." "beers" etc.
| > | > That way my users browse to the set of images he is interested in,
| > | > and can from there select "sub albums".
| > | > </Read-only-section-no-need-to-comment>
| > | >
| > | > So from the above it should be clear that current album is not one of
| > | > the shown albums. Therefore it is not possible to select the current
| > | > album for me.
|
| 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.

| > | What I was suggesting is to add the current album to the list returned
| > | by allAlbums(). In the case of your example, the album selection widget
| > | would look like this:
| > |
| > | - No Keywords       6 images
| > | - Anne Helene...    4 images
| > | - beers             2 images
| > | - holiday           8 images
| > | - new wave          2 images
| > | - silo falls over   3 images
| > | - (all images)      x images
| > |
| > | Where x would be the number of images in the album returned by
| > | currentAlbum().
| >
| > If each of the items above was check boxes, then you would gain the most
| > control, wouldn't you?
| > If they are not checkboxes, then you would not be able to cd archive both
| > "new wave" and "beers", would you?
| > If they are check boxes, the user will wonder if there are a difference
| > between checking the "(all images)" and each other checkboxes
| > individually.
|
| again, the all albums list is provided by the app. it might not make sense
| to have (all images) as an album for apps like cd archiving or
| imagegallery, but its the app to do so if it feels like.
well in such cases, it should be the application adding an "all images" item 
to the list returned from allAlbum(), not one added by libkipi.

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

Cheers
Jesper.