[Kde-imaging] RFC: (FAO Gilles) next kipi & co. generation

[Colin Guthrie]

Hi,

I don't want to be pushy, but I would really like some feedback on my
response below. Angelo has already said he cannot really comment, but I
would really value Gilles' opinion/thoughts on it as I am not familiar
enough with the concepts to really know if I'm right or wrong.

I just don't want to see the Kipi API becoming bloated with calls that
are not needed/are too specific to any given case/plugin.

Col.

Colin Guthrie wrote:
> Gilles Caulier wrote:
>> Jain have added a new method to get virtual Tags folders like Physical folder 
>> from host database. i think he have used this methods into Flickr Plugin. In 
>> digiKam 0.9.0, the kipiinterface support this method and need to be tested 
>> indeep. 
> 
> snip.
> 
>> In libkipi, there is an important wish about to give a tree folders list if 
>> the host support album == folder. I think we must fixed this point for the 
>> next release.
>>
>> Aurelien, I'm sure you libkipi with album==folder. What do you think about?
> 
> The above two points to me seem like they conflict and it would be
> better to standardise.
> 
> Personally I would prefer if the host application completely abstracted
> the fact that and "album" can just be a folder on disk. IMO the plugin
> should not know where to get an albums folder.
> 
> If Albums and Tags are treated differently then it means that any kipi
> plugin may have to handle them differently.
> 
> To me it would make more sense to have the general concept of "Albums"
> generically and perhaps have a type of album for specific handling e.g.
> "Standard, Tag, Search" could all be Album Types.
> 
> Now I may be overlooking something here so I'll explain the thought
> process behind this in the hope that someone can point out where I may
> be going wrong.
> 
> In the Gallery Plugin, I want to be able to store preferences against
> individual "Albums" and "Images" (e.g. "Sync this album to Gallery "My
> Gallery" in Remote Album "My Digikam Photos"; or "Exclude this Image
> from Sync." etc.).
> 
> The Kipi API (to my knowledge) does not support such a generic
> preferences scheme, so what was suggested to me is that I could use the
> Album's folder name as a key in KConfig style configuration file and the
> Image file name in a similar manner. This is OK, but it will only work
> for Albums where Album==folder. Therefore I could not Sync e.g. a Tag to
> a remote gallery.
> 
> Personally I feel that *ALL* "folders" supplied to a Kipi Plugin are
> virtual and that e.g. view of Albums are no different to views of Tags etc.
> 
> In addition, a kipi plugin should be able to hook into a KConfig like
> interface for each Album/Image (where in this example an Album could be
> an Album/Tag etc.)
> 
> Does this make sense? What am I missing (there /has/ to be something I'm
> missing!!!)
> 
>> In libkipi, i would to add 2 new virtual method to set/get GPS position 
>> (altitude, longitude, and latitude) to set/get this informations from the 
>> host database. In digiKam will not support yet this informations, but in the 
>> future we will do it. These new methods will work exactly like set/get 
>> orientation methods do.
> 
> This seems like a very specific method to deal with a specific plugin,
> and doesn't seem to me to be too future proof (just the first impression).
> 
> Is there no way to achieve this generically? e.g. both of these methods
> (GPS pos and orientaion) relate to editing the information that can be
> stored in an EXIF tag (AFAIK!). Can these methods be generic such that
> dealing these bits of data becomes effectively an edit operation on the
> EXIF and then just have a way to tell the host application to re-read
> the data (e.g. invalidate it's cached version of the data).
> 
> I am using EXIF as an example here as I know that this may not apply to
> all image types, but hopefully the more knowlegable people in this area
> can see the point I'm trying to make.
> 
> Just a thought.
> 
> All the best
> 
> Col.