[Kde-imaging] Selecting images for plugins

[Jesper K. Pedersen]

On Thursday 24 June 2004 16:50, Aurélien Gâteau wrote:
| > | 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 can't really see a need for this.
For the issue with an image being saved several times, can be easily fixed by 
the plugin not seeing the result of the query as a set of albums, but rather 
as one big set of images, if some images comes from several albums, then in 
the set they are only once.

| > 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().
And this is exactly what I've told you a number of times, that I can not 
implement in KimDaBa, and which is why we need the feature I suggested.

| 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?
This will look very odd to the kimdaba user. we are exactly back to the all 
images with this approach. What is wrong with my suggestion of selecting all 
sets if no one album is found to be the current one?

| > | 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.
| _______________________________________________
| Kde-imaging mailing list
| Kde-imaging at kde.org
| https://mail.kde.org/mailman/listinfo/kde-imaging

-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://ktown.kde.org/kimdaba might be the answer.