[Kde-imaging] Selecting images for plugins

[Aurélien Gâteau]

> | 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 think it should be up to the plugin to decide if the user can select 
multiple albums. In the case of the CD archiving I think it could either:
- Allow only one album to be selected
- Allow multiple albums to be selected but store each album in a subdir
- Allow multiple albums to be selected but make sure an image is not saved 
twice

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

You're right.


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

Sorry about that.
I was under the impression that you though allAlbums() should return an Album 
instead of a list of albums (sum(albums) is an album for me,  I guess I 
studied mathematics too much :-D)


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

My suggestion was to make sure the album list returned by allAlbums() 
contained the currentAlbum(), so that the widget can be filled from the 
result of allAlbums().

I just thought about something: What about filling this list like this:
- Add the content of allAlbums()
- If the currentAlbum() is not in the previous list, add an entry for it.
- Add an entry for the currentSelection()

What do you think about this?


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

Your suggestion was fine for me, after thinking about it for a while. libkipi 
could provide a default implementation like the one we are talking about to 
avoid giving too much work to the host apps.


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

Ok, got it. I agree, but I don't know how to force this.

Aurélien

PS: I'm leaving to the train station in 15 minuts, so I might not be able to 
answer before getting to Linux Tag.