libkexiv2 interface

[Jens Müller-10]

>Just take a care about KDE 4.5 beta1 when API are frozen. libkexiv2
>depand of KDE release. After this date we can only add new method, but
>no break binary.
>
>In general, we don't touch kdegraphics libs code from trunk after
>first beta release...
>
>Anyway, i'm agree also to factory libkexiv2 API to use QVariant
>methods instead duplicated method based on Qt conatainer as QString
>for ex. These changes require two stage in libkexiv2 release. One to
>add method and set old methods as deprecated. One other to remove
>deprecated methods... I already started this task in libkexiv2 with
>trunk. But not all is done of course.
>
>Best
>
>Gilles

Gilles, your message is not fully clear to me. I'm mainly speaking of that
methods:

- getExifTagRational
- setExifTagRational
- getExifTagLong
- setExifTagLong

Do you want to remove them and provide only variant-type-methods? I don't
think that this will be good, because the above ones are easier to use and the
rational method provide real fractions. I only noted that last three ones are
not capable of indexes. For beta1 we have to hurry up, but that topic is not
needed to be done in 4.5. So we also can take some time and reach a consensus
how this api should look like.

I'm not right shure about API and ABI compability. Would adding a default
parameter a problem or not?

Best, Jens
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Gilles, your message is not fully clear to me. I'm mainly speaking of that
> methods:
>
> - getExifTagRational
> - setExifTagRational
> - getExifTagLong
> - setExifTagLong
>
> Do you want to remove them and provide only variant-type-methods? I don't
> think that this will be good, because the above ones are easier to use and
> the rational method provide real fractions. I only noted that last three
> ones are not capable of indexes. For beta1 we have to hurry up, but that
> topic is not needed to be done in 4.5. So we also can take some time and
> reach a consensus how this api should look like.
>
> I'm not right shure about API and ABI compability. Would adding a default
> parameter a problem or not?

You must keep the signatures as they are currently (default argument or not
does not matter). But you can add methods, you can also add methods with the
same name but different signature.

For if there is
void foo(A a, B b, C c=C())
you can keep it and add
void foo(A a, B b, D d=D(), C c=C())

In the implementation, of course, you implement the first one by calling the
second one.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel