[Kde-imaging] libkexiv2 API: stupid questions

[Caulier Gilles]

Le mardi 30 janvier 2007 00:42, Achim Bohnet a écrit :
> Hi,
>
> Sorry for the stupid questions in advance.
> I had a look at libkexiv2.h and wondered why:
>
>   o serveral class are prefixed with 'Lib'.  Qt and KDE
>     never use 'Lib' for all classes in libraries.  So e.g.
>     Kexiv2 instead of LibKexiv2.

right. i will fix it.

>
>   o enum ImageOrientation.  Isn't there a similar Qt enum
>     that can be used here?
>

well no. it specific to Exif metadata. Qt do not support Exif.

>   o shouldn't be Iptc all capital (like GPS etc)

Exiv2 library use Exif and Iptc not EXIF and IPTC. I would do give a similar 
syntax

>
>   o there's std::string getCommentsString().  For a Qt like
>     lib, shouldn't this be QString getComment() (I assume comment
>     implies a string so no need to have 'String' in method name and
>     that it's only one comment not a list of comment(s))

Internaly, the comment is stored by a std:string. This is the format given by 
Exiv2. This method is a low level comments extraction function.

To get a QString object instead, the method     

static QString detectEncodingAndDecode(const std::string &value); 

... must be used... 



All others codes (Kipi-plugins, digiKam) use this format with 

>
>   o Exiv2::Exifdatum can't the be a Q* object be used instead?

This is require by some code in digiKam core, especially all metadata widgets.

>
>   o Both long and long int is used. Why not stick with one of them?

Right, i will take a look.

>
>   o There are lots of method using/returning.  QByteArray and
>     Exiv2::DataBuf, that sounds like an unstructred object. It's
>     usage requires detail knowledge of data structed stored in
>     those 'binary blobs'. Isn't there an Object that encapsulates
>     this, so library users does not have to care about the setting
>     byte by byte according to the specs?

QByteArray is used to give a Qt like API.

The Exiv2::DataBuf is used in digiKam core by metadata widgets.

I can fix the API to move the methods witch return Exiv2/std objects to 
the "protected" area of the class. Like this, the methods will not be public 
and can be used only if you derivated the class to do an advanced interface. 
This way will limit the future depencies.

Gilles