[Kde-imaging] Fwd: Album == Directory problem again

Jesper K. Pedersen blackie at kde.org
Mon May 10 12:03:55 CEST 2004


I'm not sure if this mail ever made it out of my laptop, so let me resent 
it....

----------  Forwarded Message  ----------

Subject: Album == Directory problem again
Date: Sunday 09 May 2004 23:24
From: "Jesper K. Pedersen" <blackie at kde.org>
To: kde-imaging at kde.org

I just found yet another plugin which assumes album == directory, namely
misc-utils which has some functions for opening an album (ie. the directory
it maps) in an external application (the apps supported are nautilus and
konqueror).

If we hit too many of these we risk to loose the backing from those
applications (e.g. digikam) which do have album==dir. So this makes me wonder
if this would be another candidate for a KIPI::feature as we discussed last
week.

The feature could be named something like AlbumEQDir.
and when that features was present a new method named, say
ImageCollection::path() would return the path for the given album (in case
the image collection was for an album), and otherwise ImageCollection::path()
might return anything - e.g. QString::null or the path of the directory for
which most images came from.

The plugins which really requires this feature (like the example above),
 could simply return an empty ActionCollection, and contribute no actions to
 the application when loaded.

An even better alternatively could be to have an X-KIPI-ReqFeatures flag to
trader which made the plugin indicate which features it requires to be
usefull. When loading plugins, the pluginloader would only load those plugins
for which the application offered all the required features.

What do you think?

Cheers
Jesper

-------------------------------------------------------

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

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


More information about the Kde-imaging mailing list