[Kde-imaging] Selecting images for plugins

[Jesper K. Pedersen]

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

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?

|
| > How about this change:
| > 1) add a new KIPI::Feature saying AllAlbumsSumUpCurrentAlbum
| > The idea behind that name is that the following is true for you, but not
| > for me: Sum( possible-current-album) == all-albums.
| > That is all-albums is a sum of all your albums.
|
| allAlbums() is a list of albums, so it can't be the sum of all our albums.
| Or maybe I misunderstood you?
Now I'm confused. Isn't that exactly how you claimed it should be implemented 
a week ago?
If I have album1, album2, ..., album20, then allAlbums would in your situation 
be a list of exactly these albums.


| > 2) develop a widget looking like the one outlined above, and make that
| > into a util function that plugins need to call, and put in their layout.
| > I suggest that all plugins have a tab page called selection with that
| > widget.
| >
| > 3) by default the current album (and we still have to figure out how to
| > find which album is current) is selected unless the feature
| > AllAlbumsSumUpCurrentAlbum is not present.
| > If it is not present (kimdaba mode ;-) the selection will be selected,
| > and if no selecetion exists, all albums will be selected.
| >
| > How about that for a compromise?
|
| I agree. Having a KIPI album selection widget would greatly improve
| consistency among plugins, but if you implement allAlbums() using my
| previous suggestion, you won't need the KIPI feature.
I'm not sure what suggestion that is, can you please elaborate.

| Still, you did not talk about Interface::Browser and what you don't like in
| it.
No I did not talk about that because I though you were in favor of your own 
suggestion, and I didn't my suggestion anymore.
I don't like it because it adds a lot of extra implementation work on each 
host application.
Besides I vaguely remembers there were a lot of other problems with it.

| > Ad2: We may want to make the tab widget (erhh icons
| > on-side-for-each-tab-widget - I dont know what that is called) the widget
| > users can get rather than just the selection widget.
| > I wonder if we somehow can force the plugins to use such a dialog to all
| > look the same to the user.
|
| Sorry, I do not understand.
See http://dotfile.adsl.dk/dump/thisone.jpg

I suggest we force each plugin to use a dialog like the above, and have it 
premade with the selection widget we are discussion.
Force if possible one way or the other.