Re: libkexiv2 interface

[Jens Müller-10]

>You can read all components of all formats with getExifTagVariant()
>currently.
>Write support is not there.
>I currently have no plan to clean that up, because I didn't know of any need
>for this.

Marcel,

it was not ment as a task up to you. It was only a calling if there is
somebody working on this.

Kipi dngconverter transfer some makernotes to standard exif tags, to provide
better interoperability. It sets for example Exif.Image.LensInfo
(rational[4]). As it uses dng-sdk exif api therefore there is currently no
problem, but you see the usecase.
Also it reads makernotes like Exif.CanonCs.Lens (Short[3]) with rational-
method as long-method is not capable of indexes. Again, you see the usecase.

This is for a project that resists in KDE trunk, there are maybee some
projects out willing to take kdegraphics-libraries we don't know of. Also,
what we get today in that api we can use in future without versioning-
problems.


Perhaps I'm a bit to focussed such api consistencies, but should it not only
be to add a default parameter like in getExifTagRational?

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

[Marcel Wiesweg]

> This is for a project that resists in KDE trunk, there are maybee some
> projects out willing to take kdegraphics-libraries we don't know of. Also,
> what we get today in that api we can use in future without versioning-
> problems.
>
>
> Perhaps I'm a bit to focussed such api consistencies, but should it not
> only be to add a default parameter like in getExifTagRational?

Yes sure, it would be no problem. We have to keep the old signatures for
binary compatibility, but can add new methods. We also have to take a look at
KDE release schedule for API freezes. Other than that, libkexiv2 is open for
extensions.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

2010/5/8 Marcel Wiesweg <[hidden email]>:

>
>> This is for a project that resists in KDE trunk, there are maybee some
>> projects out willing to take kdegraphics-libraries we don't know of. Also,
>> what we get today in that api we can use in future without versioning-
>> problems.
>>
>>
>> Perhaps I'm a bit to focussed such acompatibility.pi consistencies, but should it not
>> only be to add a default parameter like in getExifTagRational?
>
> Yes sure, it would be no problem. We have to keep the old signatures for
> binary compatibility, but can add new methods. We also have to take a look at
> KDE release schedule for API freezes. Other than that, libkexiv2 is open for
> extensions.
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

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