[Kde-imaging] currentScope and friends

Jesper K. Pedersen blackie at kde.org
Fri Jun 4 15:44:48 CEST 2004


On Friday 04 June 2004 15:23, Aurélien Gâteau wrote:
| Le vendredi 4 Juin 2004 12:10, Jesper K. Pedersen a écrit :
| > On Friday 04 June 2004 12:00, Aurélien Gâteau wrote:
| > | Le vendredi 4 Juin 2004 00:09, Jesper Pedersen a écrit :
| > | >   I therefore added a function called currentScope(),
| > |
| > | I've been wondering about the currentAlbum() and currentSelection()
| > | thing for a while and I'm afraid we will see inconsistency in the way
| > | plugins select which files they'll work on. Some might work on
| > | currentAlbum(), some on currentSelection(), some others on
| > | currentScope() and yet some others might let the user choose among
| > | allAlbums().
| >
| > I agree that most application should just use currentScope, which is why
| > I replaced all the code trying first to use the selection, then the
| > album.
| >
| > If the cure is to remove currentAlbum and currentSelection altogether,
| > I'm not so sure about. I'd much rather solve the issue by writting good
| > documentation for the methods suggesting the user to use
| > currentSelection(), unless they have a very good reason not to.
|
| I can't see why a plugin would use currentSelection() instead of
| currentScope() and I think it's better to add methods when they are needed
| rather than just in case. This prevents API bloat.
sure, but on the other hand adding methods later on breaks binary 
compatibility. Its a trade of.
I can't tell you which situation you only want a selection and not the 
currentScope(), but I'm sure there will be some if we dont include this 
method.

| > | I suggest we only provide a currentScope() and a allAlbums() methods.
| > | Most plugins should provide a list filled with the content of
| > | allAlbums() with the currentScope() item selected so that the user do
| > | not have to select it. Maybe we could even implement a
| > | KIPI::AlbumListView widget.
| > |
| > | What do you think about this?
| >
| > That assumes that currentAlbum is one of the albums in allAlbums(), which
| > is not true for KimDaBa.
|
| Then your implementation of allAlbums() is broken. What's the goal of such
| a method if it does not return *all* albums? or maybe you will tell me that
| Album!=ImageCollection? This is getting way too complex.
Lets get it over with.
Please stop comming with such aggressive statements as the above!
Saying that "Then your implementation of allAlbums() is broken." doesn't 
really help. We need to work together here, ALL of use need to give in to 
compromises, our applications are different, so your way doesn't need to be 
the only correct one!

And now to the technical part.
KimDaBa do not store things in albums, and given that KimDaBa do not have any 
mapping whatsoever to where files is on the harddisk, I can not come up with 
a album/all album concept that fits all situations.

I've given in on several points regarding this, to get things working for all 
of us. Should it be my way, there was no allAlbums() at all.

The way I implemented the all album is that I take the current scope (that is 
use the set of images the user has so far browsed to), and segment them using 
the category "keyword"

This has the drawback that one image can be in several albums (You can have as 
many keywords set for one image as you like), and it has the drawback that 
the current album is not one of the albums - actually the current album is 
the sum of all the albums.

Thus changing all plugins to use allAlbums all the time, wouldn't really make 
much sense to KimDaBa.


More information about the Kde-imaging mailing list