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

[Renchi Raju]

On Fri, 10 Sep 2004, Jesper K. Pedersen wrote:

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

with pleasure.

renchi