[Kde-imaging] RFC: next kipi & co. generation

[Colin Guthrie]

Caulier Gilles wrote:
>> A simplistic API could be something like this:
>>
>> class ImageCollection {
>> ...
>> public:
>>   const QValueList<ImageCollection>& subCollections() const;
>> ...
>> }
>>
>> But it might not be very efficient. At least for the image collection
>> dialog, it would be nice to have a method like this:
>>
>>   bool hasSubCollections() const;
>>
>> So that ImageCollectionDialog can make its items expandable without
>> retrieving the full list of sub collections.
>>
>> It could be made more flexible and efficient by introducing an
>> ImageCollectionIterator class, similar to QListViewItemIterator. This
>> iterator would be implemented by the host app, allowing it to store the sub
>> collections in the best way possible.
>>
> 
> Sounds good for me Aurélien. 

I wholeheartedly agree! As I was trying to explain elsewhere in this
thread, I think this kind of structure should be the only way for
plugins to determin the heirarchy of a host applications Images.

I think the path() and isDirectory() methods should be removed (as it
should be irrelevent to plugins).


I would also like the host application to make available to Kipi Plugins
a KConfig style interface for each ImageCollection to allow plugins to
store settings for each album, tag etc. With this I would be able to
implement lots of nice "synchronisation" features in the Gallery Plugin.

I would also like the host application to make a similar KConfig
interface available for ImageInfo also.

Obviously for non-permanent collections (like e.g. the current
selection?) it would not make sense to provide a KConfig interface, so
the plugin should check to see that it is provided before using it!

Also it would be optional for a host application to provide this, so it
doesn't have to be implemented but the host app would loose certain
functionality of the plugin.

WDYT?

Col