[Kde-imaging] few questions and comments...

[Jesper K. Pedersen]

On Wednesday 08 September 2004 18:57, Renchi Raju wrote:
| On Wed, 8 Sep 2004, Jesper K. Pedersen wrote:
| > On Monday 06 September 2004 23:39, Renchi Raju wrote:
| > | On Mon, 6 Sep 2004, Jesper K. Pedersen wrote:
| > | > On Monday 06 September 2004 17:58, Renchi Raju wrote:
| > | > | jesper,gilles... ok to remove AlbumEQDir from features list and
| > | > | moved to ImageCollection?
| > | >
| > | > Well the point is that this plugin would not make any sense if the
| > | > host app did not have this feature, would it.
| > | >
| > | > So therefore this plugin should put this requirement in the desktop
| > | > file (as it actually does), so host applications which do not have
| > | > this setup simply can ignore this plugin.
| > | >
| > | > So I don't think it should be removed, maybe we should add your
| > | > suggested method in addition instead.
| > |
| > | in our case (digiKam), some of the albums are directories and some of
| > | the albums are not. so unlike AlbumEQDir which makes a black and white
| > | distinction (app has the feature or app doen't have the feature), we
| > | fall into the grey area. only at runtime, can we determine whether the
| > | album is a directory or not.
| >
| > Still, we need to rework, so these use currentSelection(), rather than
| > currentScope() again, didn't we?
|
| i believe this is a different issue.
|
| just to reiterate: there are three methods for a plugin to access the
| current imagecollection from the app, currentAlbum, currentSelection,
| currentScope which return all items in current view, selected items in
| current view and app-dependent return of either currentSelection or
| currentAlbum respectively.
|
| in digikam currentScope always returns currentSelection. other apps have
| the flexibility of returning currentAlbum instead, which imho is not the
| best thing to do for an app, since we have plugins like jpeglossless which
| run non-interactively.
|
| its upto the app developer to decide what to return from currentScope. i
| was in favor of removing the currentScope option completely, because it
| can cause unexpected results for the user, but that again is for the app
| developer to decide what his/her users' expect.
|
| so, my take on the issue is, i don't care either way if the currentScope
| function is retained or removed, as long as plugins take care to use the
| "correct" function depending on their context, which i believe they
| currently do.
I was the one suggestion this method, and in the meantime I've changed my 
mind, so I suggest that current scoped is removed completely.

I'm going away on course the next two week, with only little if any internet, 
so Renchi, would you please take care of killing currentScope.

Cheers
Jesper