Important changes from svn trunk : extragear/libs removed...

[Gilles Caulier-4]

Hi all.

Severals changes have be done in svn trunk about extragear/libs. This
folder have been removed and following moves have been done :

kipi-plugins => extragear/graphics
libkipi => kdegraphics
libkexiv2 => kdegraphics
libkdcraw => kdegraphics

Please checkout your local repository. Thanks in advance

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

[Aurélien Gâteau]

Gilles Caulier wrote:
> Hi all.
>
> Severals changes have be done in svn trunk about extragear/libs. This
> folder have been removed and following moves have been done :
>
> kipi-plugins => extragear/graphics
> libkipi => kdegraphics
> libkexiv2 => kdegraphics
> libkdcraw => kdegraphics

More precisely:
libkipi => kdegraphics/libs
libkexiv2 => kdegraphics/libs
libkdcraw => kdegraphics/libs

And for the sake of consistency, I think libksane should be moved to
kdegraphics/libs too.

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

martedì 03 giugno 2008, Gilles Caulier ha scritto:

> Hi all.
>
> Severals changes have be done in svn trunk about extragear/libs. This
> folder have been removed and following moves have been done :
>
> kipi-plugins => extragear/graphics
> libkipi => kdegraphics
> libkexiv2 => kdegraphics
> libkdcraw => kdegraphics
>
> Please checkout your local repository. Thanks in advance
>

That is a great news and a great day! I believe that

is the right prize for your great work!

Thanks,
        Angelo

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

martedì 03 giugno 2008, Aurélien Gâteau ha scritto:

> Gilles Caulier wrote:
> > Hi all.
> >
> > Severals changes have be done in svn trunk about extragear/libs. This
> > folder have been removed and following moves have been done :
> >
> > kipi-plugins => extragear/graphics
> > libkipi => kdegraphics
> > libkexiv2 => kdegraphics
> > libkdcraw => kdegraphics
>
> More precisely:
> libkipi => kdegraphics/libs
> libkexiv2 => kdegraphics/libs
> libkdcraw => kdegraphics/libs
>
> And for the sake of consistency, I think libksane should be moved to
> kdegraphics/libs too.

Well so which is the release date for those libraries now?

Angelo



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

[Aurélien Gâteau]

Angelo Naselli wrote:

> martedì 03 giugno 2008, Aurélien Gâteau ha scritto:
>> Gilles Caulier wrote:
>>> Hi all.
>>>
>>> Severals changes have be done in svn trunk about extragear/libs. This
>>> folder have been removed and following moves have been done :
>>>
>>> kipi-plugins => extragear/graphics
>>> libkipi => kdegraphics
>>> libkexiv2 => kdegraphics
>>> libkdcraw => kdegraphics
>> More precisely:
>> libkipi => kdegraphics/libs
>> libkexiv2 => kdegraphics/libs
>> libkdcraw => kdegraphics/libs
>>
>> And for the sake of consistency, I think libksane should be moved to
>> kdegraphics/libs too.
> Well so which is the release date for those libraries now?

They will be at least released everytime KDE makes a new release. The
good news is: you won't have to build tarballs anymore :). Whether there
should be interim releases should be discussed, but interim releases are
usually painful...

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

> >> More precisely:
> >> libkipi => kdegraphics/libs
>
> They will be at least released everytime KDE makes a new release. The
> good news is: you won't have to build tarballs anymore :). Whether there
> should be interim releases should be discussed, but interim releases are
> usually painful...

BTW, now you/we could make kipi support as default in gwenview and not
optional...

Angelo

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

[Marcel Wiesweg]

> Hi all.
>
> Severals changes have be done in svn trunk about extragear/libs. This
> folder have been removed and following moves have been done :
>
> kipi-plugins => extragear/graphics
> libkipi => kdegraphics
> libkexiv2 => kdegraphics
> libkdcraw => kdegraphics

What are the rules for binary compatibility for these libraries now?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/6/4 Marcel Wiesweg <[hidden email]>:

>> Hi all.
>>
>> Severals changes have be done in svn trunk about extragear/libs. This
>> folder have been removed and following moves have been done :
>>
>> kipi-plugins => extragear/graphics
>> libkipi => kdegraphics
>> libkexiv2 => kdegraphics
>> libkdcraw => kdegraphics
>
> What are the rules for binary compatibility for these libraries now?

These libraries are not yet released. so it's always time to fix API
until KDE4.1. After, the BC for libkexiv2/libkipi/libkdcraw need to be
preserved.

I think it's not a problem for libkipi and libkdcraw. perhaps
libkexiv2 need to be fixed to extract GPS info from XMP.

For libkdcraw, we need to use libraw instead a dcraw.c. I think we can
do it without to break BC.

Or perhaps i forget something ?

But we need to take a care about BC for the future, especially after
KDE4.1. These libraries will be published with KDE now. This have
advantages and disadvantages of course.

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

[Marcel Wiesweg]

> > What are the rules for binary compatibility for these libraries now?
>
> These libraries are not yet released. so it's always time to fix API
> until KDE4.1. After, the BC for libkexiv2/libkipi/libkdcraw need to be
> preserved.
>
> I think it's not a problem for libkipi and libkdcraw. perhaps
> libkexiv2 need to be fixed to extract GPS info from XMP.

Adding non-virtual methods is now problem usually. As to virtual methods, I
see no problem for libkexiv2 with adding or removing virtual methods (and
thus breaking BC)

>
> For libkdcraw, we need to use libraw instead a dcraw.c. I think we can
> do it without to break BC.

There are a few protected virtual methods for the raw decoding process that
seem quite specific to using dcraw in a separate process. When switching to
libraw we may well have other needs. I have no overview on this currently.
Even the name of the library suggests it is using dcraw ;-)

>
> Or perhaps i forget something ?
>
> But we need to take a care about BC for the future, especially after
> KDE4.1. These libraries will be published with KDE now. This have
> advantages and disadvantages of course.
>
> Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/6/4 Marcel Wiesweg <[hidden email]>:

>
>> > What are the rules for binary compatibility for these libraries now?
>>
>> These libraries are not yet released. so it's always time to fix API
>> until KDE4.1. After, the BC for libkexiv2/libkipi/libkdcraw need to be
>> preserved.
>>
>> I think it's not a problem for libkipi and libkdcraw. perhaps
>> libkexiv2 need to be fixed to extract GPS info from XMP.
>
> Adding non-virtual methods is now problem usually. As to virtual methods, I
> see no problem for libkexiv2 with adding or removing virtual methods (and
> thus breaking BC)
>
>>
>> For libkdcraw, we need to use libraw instead a dcraw.c. I think we can
>> do it without to break BC.
>
> There are a few protected virtual methods for the raw decoding process that
> seem quite specific to using dcraw in a separate process. When switching to
> libraw we may well have other needs. I have no overview on this currently.
> Even the name of the library suggests it is using dcraw ;-)

Right BC will be broken if we remove these virtual methods.

So the better way is to have a new "libkraw" libary, using "libraw"
and providing the same API than current "libkdcraw".

This is possible because "libraw" API respect 90% of dcraw options
(excepted color management options witch need to be emulated with
"lcms" API into libkraw - like dcraw do in fact)

If we provide same API between libkraw and libkdcraw, porting and
application will be very easy and fast.

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