RFC: The breakage of the year, our libraries

Hi,
following the thread
http://thread.gmane.org/gmane.comp.kde.digikam.devel/20079/focus=20086
We've found a strange digikam behaviour, it shows the libraries it needed
at compile time, at least the ones we, as kipi team, release.

That could be easily solved by adding a static method to our libraries
returning the version.
I made two patches (libkexiv2 and libkdcraw) with a possible implementation,
I'd prefer to remove old version.h, but we could leave it and take that
value instead.

I haven't done one for libkipi, since i'm not a real libkipi hacker and
I'm not sure where to put the method...

Anyway that means breaking all the binary compatibility... so i'd prefer
to have feedbacks before doing something.
Breaking libkipi though can give us a chance to add some new methods (if
any are somewhere into your mind ;) )

Another libkipi issue, i've worked on is about
http://bugs.kde.org/show_bug.cgi?id=88118
(that gets me annoyed :/), I've implemented it and now the folder is selected,
but it seems has a wrong side effect in digikam (gwenview is not affected),
double clicking on new folder/album allows digikam to show new imported picture,
while my patch doesn't, i should have missed something and i need help here.
Gilles i'd like to talk about this patch with you, other ones are attached here instead.

Waiting for comments,
        Angelo

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

> I haven't done one for libkipi, since i'm not a real libkipi hacker and
> I'm not sure where to put the method...
Ok since Gilles wants to take version.h i'll propose the following way, that
i don't like very much though, but it should work as well. The attached patch
is for libkipi, but i'll apply to all if ok to avoid too many places in which
adding the version (I know i could patch configure.in.in and propagate... maybe
in future).

At last i patched also configure.in.in that should avoid VISIBILITY warning,
but i don't know if it can have some obscure to me side effects...

Any comments?
        Angelo

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

How about attaching the patch? :)

Angelo

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

[Aurélien Gâteau]

Angelo Naselli wrote:
[snip]
> Anyway that means breaking all the binary compatibility... so i'd prefer
> to have feedbacks before doing something.
[snip]

If you only add new methods, you don't break binary compatibility. Only
problem is applications linking to new lib won't work with old lib.
Applications linking to old lib will continue to work with new lib.

Aurélien

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

[Gilles Caulier-4]

2008/1/6, Aurélien Gâteau <[hidden email]>:

Angelo Naselli wrote:
[snip]
> Anyway that means breaking all the binary compatibility... so i'd prefer
> to have feedbacks before doing something.
[snip]

If you only add new methods, you don't break binary compatibility. Only
problem is applications linking to new lib won't work with old lib.
Applications linking to old lib will continue to work with new lib.

Aurélien,

I would to backport some work form KDE4 to KDE3 to improve the library. This will broke the BC...

Gilles

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