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

[=?UTF-8?Q?Aur=C3=A9lien_G=C3=A2teau_]

On Wed, 27 Sep 2006 21:54:12 +0100, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Caulier Gilles wrote:
>>> 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 agree. Especially since a plugin using these functions would have to be 
tested on different hosts to ensure it works correctly everywhere. 

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

Would be nice indeed.

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

Hmm, beware of "flexibility overflow". While it sounds nice, it means a plugin
should be tested on different hosts to make sure it works consistently on all
of them.

I would rather only add a isPermanent() method to ImageCollection so that a 
plugin can determine if it can store settings. If an host app doesn't want to
implement support for permanent settings it only needs to return false in 
isPermanent(). This could even be the default implementation of isPermanent().

Aurélien