[Kde-imaging] Selecting images for plugins

[Renchi Raju]

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).

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.

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

> 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'.

i will try and address the other comments, once i have heard back from you
all.

renchi