libkdcraw from graphics gsoc-branch

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

libkdcraw from graphics gsoc-branch

Jens Müller-10
Gilles,

you put some effords to prepare the inclusion of libraw 0.12 for kde 4.7 in
libkdcraw on gsoc-branch. But there are some pitfalls I think:

First the library does not build through missing amaze_demosaic_RT.cc from
demosaic-pack-GPL3 folder. A think only a missing checkin, so not the big
thing?

The main problem is about ABI-compability. You extend decoding structures to
fetch new libraw parameters. But here comes the scenario: If someone build
digikam 1.6 and link it against libkdcraw from KDE 4.6 and then upgrade to KDE
4.7 the application will crash I think. Ugly, but the right way will be a
duplicate of the structure and the calling method. Am I right? Marcel, what do
you think?

Regards, Jens
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

Gilles Caulier-4
2010/11/24 Jens Müller <[hidden email]>:
> Gilles,
>
> you put some effords to prepare the inclusion of libraw 0.12 for kde 4.7 in
> libkdcraw on gsoc-branch. But there are some pitfalls I think:
>
> First the library does not build through missing amaze_demosaic_RT.cc from
> demosaic-pack-GPL3 folder. A think only a missing checkin, so not the big
> thing?

arf. i certainly forget to add a file in svn. I will fix it

>
> The main problem is about ABI-compability. You extend decoding structures to
> fetch new libraw parameters. But here comes the scenario: If someone build
> digikam 1.6 and link it against libkdcraw from KDE 4.6 and then upgrade to KDE
> 4.7 the application will crash I think. Ugly, but the right way will be a
> duplicate of the structure and the calling method. Am I right? Marcel, what do
> you think?

this is why we have ABI id and API id.

Note: The BC is broken if you remove API, not when you add new one...

Marcel ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

"Jens Müller"

> > The main problem is about ABI-compability. You extend decoding
> structures to
> > fetch new libraw parameters. But here comes the scenario: If someone
> build
> > digikam 1.6 and link it against libkdcraw from KDE 4.6 and then upgrade
> to KDE
> > 4.7 the application will crash I think. Ugly, but the right way will be
> a
> > duplicate of the structure and the calling method. Am I right? Marcel,
> what do
> > you think?
>
> this is why we have ABI id and API id.
>
> Note: The BC is broken if you remove API, not when you add new one...
>
> Marcel ?
>

Please correct me if I'm wrong. If the structure is used as a in parameter at library side there should be a problem. The application linked against old lib will allocate a structure in size of the old one. The new library with extended structure will parse the new size. So the there is a out of struture memory call at some place?

Jens

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

Gilles Caulier-4
In reply to this post by Jens Müller-10
2010/11/24 Jens Müller <[hidden email]>:
> Gilles,
>
> you put some effords to prepare the inclusion of libraw 0.12 for kde 4.7 in
> libkdcraw on gsoc-branch. But there are some pitfalls I think:
>
> First the library does not build through missing amaze_demosaic_RT.cc from
> demosaic-pack-GPL3 folder. A think only a missing checkin, so not the big
> thing?
>
Fixed...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

Marcel Wiesweg
In reply to this post by "Jens Müller"

> Please correct me if I'm wrong. If the structure is used as a in parameter
> at library side there should be a problem. The application linked against
> old lib will allocate a structure in size of the old one. The new library
> with extended structure will parse the new size. So the there is a out of
> struture memory call at some place?

Yes, you are right.
Compare for example with QStyleOptionViewItem in Qt: When the parameter, which
is passed by value, gets new fields, there is need for QStyleOptionViewItemV2,
...V3, ...V4.
Of course, if the ABI number is increased with the change of the structure,
all is well.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

Gilles Caulier-4
2010/11/25 Marcel Wiesweg <[hidden email]>:

>
>> Please correct me if I'm wrong. If the structure is used as a in parameter
>> at library side there should be a problem. The application linked against
>> old lib will allocate a structure in size of the old one. The new library
>> with extended structure will parse the new size. So the there is a out of
>> struture memory call at some place?
>
> Yes, you are right.
> Compare for example with QStyleOptionViewItem in Qt: When the parameter, which
> is passed by value, gets new fields, there is need for QStyleOptionViewItemV2,
> ...V3, ...V4.
> Of course, if the ABI number is increased with the change of the structure,
> all is well.


and i increased ABI id of course, as API id.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: libkdcraw from graphics gsoc-branch

"Jens Müller"

> > Yes, you are right.
> > Compare for example with QStyleOptionViewItem in Qt: When the parameter,
> which
> > is passed by value, gets new fields, there is need for
> QStyleOptionViewItemV2,
> > ...V3, ...V4.
> > Of course, if the ABI number is increased with the change of the
> structure,
> > all is well.
>
>
> and i increased ABI id of course, as API id.
>
> Gilles
> _______________________________________________


Yes Gilles, all fine then. I just worry about possible new crash reports.

Jens
--
GMX DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel