[Kde-imaging] Album == Directory problem again

Aurélien Gâteau aurelien.gateau at free.fr
Mon May 10 18:24:00 CEST 2004


Le Dimanche 9 Mai 2004 23:24, Jesper K. Pedersen a écrit :
> 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?

This is a good idea. I especially like the X-KIPI-ReqFeatures thing. 
Concerning the acquire plugins, I think we should have a method like 
Interface::incomingImagePath() which would be the prefered place where 
acquire plugins would put their images. This can also be defined as a feature 
if not all app can support it.

Regards,
  Aurélien



More information about the Kde-imaging mailing list