Future plans : 0.9.2-final and KDE4 port...

[Gilles Caulier-4]

Hi all,

See below the future digiKam plans :

DIGIKAM 0.9.2 FINAL RELEASE:
---------------------------------------------

The 0.9.2-final release date is near. Like Gerhard will back at home today (:=))), final release will be done at soon.

Gerhard, just a little tip : the libkdcraw need to be released again following #146464 B.K.O file. the library have been patched to fix this bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...

Angelo, Achim : Please take a care to provide a new package of this library for Mandriva and Debian at the same time than digiKam 0.9.2. thanks in advance...

DIGIKAM 0.9.3 RELEASE:
------------------------------------

The future KDE3 digiKam release will be a bugfix release. No new features will be added. The code will still into branches/extragear/kde3/graphics/digikam.

Because me and Marcel we will concentrate the efforts to port digiKam to KDE4, the 0.9.3 release source code can be delegate to anothers guys if there are volumters in the room. The job is simple : backport the small bug fixes done in KDE4 port, when this can be easily backported of course. Marcel and me we will annotate and post the commits witch can be backported in [hidden email] mailling list. This will simplify this job.

I will be happy if anothers begineer developpers can do this task. it's not really complicated and it a good stuff to learn source code... This is not a pejorative comment : all developpers come like beginneer at startup (me and Marcel included (:=))).

Marcel and me we will very busy to port, test, and stabilize KDE4 source code. New contributors are welcome and all help will be very appreciate.

DIGIKAM 0.10.0 RELEASE (KDE4 PORT):
---------------------------------------------------------

This is the future : the famous KDE4/Qt4/CMake port....

The implementation will be done in trunk/extragear/graphics/digikam. Actually nothing is done. In fact, Marcel, will sync and move the current development branch named 'db-consolidation' ( http://websvn.kde.org/branches/work/digikam-dbconsolidation) to trunk. This branch have been created by Marcel few month ago to create a new database backend and factorize the database management code in digiKam core.

Why working on DB now ?

Because the 0.9.x serie have been dedicaced to add 16 bits color depth support and others important features like metadata management, color management, RAW file support, etc... _Nothing_ have been done about database. It's urgent now to work on it.

This is want mean than DB structure will change in the future. We have already a list of new informations to host in DB like :

- Photo informations to perform search of images based on Exif/IPTC,
- GPS info to perform search of images on a map (imaging a bar where you can query something like "i want to find all pictures taken around Paris"),
- Haar matrix to perform search of duplicate images (http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
- Editor Actions List to perform non destructive edition of pictures (technics used by Nikon NX soft for ex.)

This is a small list of future informations hosted by DB. Others data can be add of course and discussion is open about this subject (Arnd...).

Why not use the new DB backend from Marcel with KDE3 branch ?

Like Marcel said in private mail, the backend is not yet completed, and he want to use the new QT4 API about to drive DB kernel. Qt4 APi will simplify developpement about DB. No need to reinvent the wheel.

Also, all changes in DB will fragilize digiKam until the code will be stabilized. This is a risk to corrupt something in DB with future bugs. DB management is a tiedous job. We won't to take a risk with these important informations used by digiKam users.

This is why we have decided to sync the new DB implementation with 0.10.0 release at the same time than KDE4 port.

Important : when digiKam 0.10.0 implementation will be started and will run, i recommend to all users to use a _dedicaced_ album library path to perform tests. This will be dangerous to use it in production until we have stabilized source code! I will post a comments in Blog in the future to aware users about this problem...

How many time will take KDE4 port ?

Good question : this depand of free time available. There are some scripts to use to simplify task, but personally i don't like script source code converters (:=))). The code can be completly unreadable and this is not the better way to learn the new API.

I think we can plan to have a full port of digiKam for september (2007 of course)...


KIPI-PLUGINS-LIBKDCRAW-LIBKEXIV2-LIBKIPI KDE4 PORT ???
-------------------------------------------------------------------------------------------

Well, i have already started the KDE4 port in trunk :

http://websvn.kde.org/trunk/extragear/libs/

- libkipi : done.
- libkexiv2 : done.
- libkdcraw : done.
- kipi-plugins : 3 plugins ported : WallPaper, JpegLossLess, and TimeAdjust. Next one will be RawConverter.

Like all shared libs are ported, we will take less time to port digiKam...

Of course like none kipi host is ported actually, this code is not yet tested and can include bugs (:=)))...

Note : i have ported these codes without using scripts. All have be done by hands.

I hope than others kipi-plugins mainteners will port plugins code during this summer...

------------------------------------------------------------------------------------------------------------------

Feel free to comments this post. All contributions welcome of course. Thanks in advance...

Cheers

Gilles Caulier

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

[Arnd Baecker]

On Mon, 11 Jun 2007, Gilles Caulier wrote:

[...]

> This is want mean than DB structure will change in the future. We have
> already a list of new informations to host in DB like :
>
> - Photo informations to perform search of images based on Exif/IPTC,
> - GPS info to perform search of images on a map (imaging a bar where you can
> query something like "i want to find all pictures taken around Paris"),
> - Haar matrix to perform search of duplicate images (
> http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
> - Editor Actions List to perform non destructive edition of pictures
> (technics used by Nikon NX soft for ex.)
>
> This is a small list of future informations hosted by DB. Others data can be
> add of course and discussion is open about this subject (Arnd...).

There is one important decision about the database:
Will it be possible to easily add additional fields
   - with new digikam releases (eg. 10.1, 10.2, ...)
   - or even by the user
?

Reason: new ideas might require new database fields.
If this has to wait (like for example the GPS stuff right now),
for a change from 0.10 to 0.11, this can delay such additions
for a long time. If this is the case, then
we really should  think very hard about additional fields
for the database right now, to be able to leave it unchanged.

However, if additions are simple and don't break
anything (and this has to be absolutely guaranteed, IMO!),
then only the additional fields needed right now should
be added.

Independent of this it might be a good idea to make a survey
on the users list, what additional fields might be useful -
there might be some cool ideas lurking around!
If you think that this does make sense, I could set up such
an e-mail, and post it on digikam-users.

Just my 2 cents,

Arnd



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

[Arnd Baecker]

On Mon, 11 Jun 2007, Gilles Caulier wrote:

> DIGIKAM 0.9.3 RELEASE:
> ------------------------------------
>
> The future KDE3 digiKam release will be a bugfix release. No new features
> will be added. The code will still into
> branches/extragear/kde3/graphics/digikam.

Hmm, this would mean, that nothing new
(no wishes from the B.K.O. etc.) can be added until
the KDE4 port of digikam is operational (Sept 2007)?

((I understand the reasoning behind it, but it might also
block people from contributing ...))

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

[Gilles Caulier-4]

2007/6/12, Arnd Baecker <[hidden email]>:

On Mon, 11 Jun 2007, Gilles Caulier wrote:

> DIGIKAM 0.9.3 RELEASE:
> ------------------------------------
>
> The future KDE3 digiKam release will be a bugfix release. No new features
> will be added. The code will still into
> branches/extragear/kde3/graphics/digikam.

Hmm, this would mean, that nothing new
(no wishes from the B.K.O. etc.) can be added until
the KDE4 port of digikam is operational (Sept 2007)?

((I understand the reasoning behind it, but it might also
block people from contributing ...))

Well, if new features are added to KDE3 branches, it must be backported to KDE4 too. Do you understand the problem : it's a double job witch can introduce bugs (:=)))

This can be done for small features of course, easily backportable between branches...

Gilles

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

[Arnd Baecker]

On Tue, 12 Jun 2007, Gilles Caulier wrote:

> 2007/6/12, Arnd Baecker <[hidden email]>:
> >
> > On Mon, 11 Jun 2007, Gilles Caulier wrote:
> >
> > > DIGIKAM 0.9.3 RELEASE:
> > > ------------------------------------
> > >
> > > The future KDE3 digiKam release will be a bugfix release. No new
> > features
> > > will be added. The code will still into
> > > branches/extragear/kde3/graphics/digikam.
> >
> > Hmm, this would mean, that nothing new
> > (no wishes from the B.K.O. etc.) can be added until
> > the KDE4 port of digikam is operational (Sept 2007)?
> >
> > ((I understand the reasoning behind it, but it might also
> > block people from contributing ...))
>
>
> Well, if new features are added to KDE3 branches, it must be backported to
> KDE4 too. Do you understand the problem : it's a double job witch can
> introduce bugs (:=)))

I perfectly understand - and it is more work.

> This can be done for small features of course, easily backportable between
> branches...

Alright.

Should one try to get as many bugs fixed before the KDE4 branch
gets active?

For example, there are a couple of B.K.O. entries (27 in total)
which appear to contain a patch.
Should I have a look at all of them and report if I think it is
worth that an expert has a look?

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

[Gilles Caulier-4]

2007/6/12, Arnd Baecker <[hidden email]>:

On Tue, 12 Jun 2007, Gilles Caulier wrote:

> 2007/6/12, Arnd Baecker <[hidden email]>:
> >
> > On Mon, 11 Jun 2007, Gilles Caulier wrote:
> >
> > > DIGIKAM 0.9.3 RELEASE:
> > > ------------------------------------
> > >
> > > The future KDE3 digiKam release will be a bugfix release. No new
> > features
> > > will be added. The code will still into
> > > branches/extragear/kde3/graphics/digikam.
> >
> > Hmm, this would mean, that nothing new
> > (no wishes from the B.K.O . etc.) can be added until
> > the KDE4 port of digikam is operational (Sept 2007)?
> >
> > ((I understand the reasoning behind it, but it might also
> > block people from contributing ...))
>
>
> Well, if new features are added to KDE3 branches, it must be backported to
> KDE4 too. Do you understand the problem : it's a double job witch can
> introduce bugs (:=)))

I perfectly understand - and it is more work.

> This can be done for small features of course, easily backportable between
> branches...

Alright.

Should one try to get as many bugs fixed before the KDE4 branch
gets active?

For example, there are a couple of B.K.O. entries (27 in total)
which appear to contain a patch.
Should I have a look at all of them and report if I think it is
worth that an expert has a look?

Yes, you can do it. You can short these entries by vote...

Gilles

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

[Marcel Wiesweg]

> On Mon, 11 Jun 2007, Gilles Caulier wrote:
>
> [...]
>
> > This is want mean than DB structure will change in the future. We have
> > already a list of new informations to host in DB like :
> >
> > - Photo informations to perform search of images based on Exif/IPTC,
> > - GPS info to perform search of images on a map (imaging a bar where you
> > can query something like "i want to find all pictures taken around
> > Paris"), - Haar matrix to perform search of duplicate images (
> > http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
> > - Editor Actions List to perform non destructive edition of pictures
> > (technics used by Nikon NX soft for ex.)
> >
> > This is a small list of future informations hosted by DB. Others data can
> > be add of course and discussion is open about this subject (Arnd...).
>
> There is one important decision about the database:
> Will it be possible to easily add additional fields
>    - with new digikam releases (eg. 10.1, 10.2, ...)

If you look at amarok, they have had about 20 schema revisions.

We definitely plan to add more database fields. Adding a table with additional
information is easy, it becomes more tricky if the change makes the database
incompatible with previous versions. In this case, the application has to
detect it and refuse to start.

As current versions cannot do this, my current plan is to move the db file to
digikam4.db (where 3->4 nicely coincides with KDE3/KDE4) and any version from
now on will be able to refuse to start if it does not understand the schema.
Users usually do not need to downgrade a version. If they have to, there'd be
a severe regression which we should have fixed first ;-)
So the possible missing compatibility (not for all schema upgrades necessary )
mostly affects beta testers which might have a reason to use a stable
version. In this case, we will make this clear in the release of beta1 - with
schema changes only occuring in alpha state, and the option to specify
different db files in config / on the command line.

>    - or even by the user

The problem is that the application at least needs to provide means to read
and write the added values. If it does not know at all about the nature of
the data, this will be only very basic support.

> ?
>
> Reason: new ideas might require new database fields.
> If this has to wait (like for example the GPS stuff right now),
> for a change from 0.10 to 0.11, this can delay such additions
> for a long time. If this is the case, then
> we really should  think very hard about additional fields
> for the database right now, to be able to leave it unchanged.
>
> However, if additions are simple and don't break
> anything (and this has to be absolutely guaranteed, IMO!),
> then only the additional fields needed right now should
> be added.

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

[Arnd Baecker]

On Tue, 12 Jun 2007, Marcel Wiesweg wrote:

> > On Mon, 11 Jun 2007, Gilles Caulier wrote:
> >
> > [...]
> >
> > > This is want mean than DB structure will change in the future. We have
> > > already a list of new informations to host in DB like :
> > >
> > > - Photo informations to perform search of images based on Exif/IPTC,
> > > - GPS info to perform search of images on a map (imaging a bar where you
> > > can query something like "i want to find all pictures taken around
> > > Paris"), - Haar matrix to perform search of duplicate images (
> > > http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
> > > - Editor Actions List to perform non destructive edition of pictures
> > > (technics used by Nikon NX soft for ex.)
> > >
> > > This is a small list of future informations hosted by DB. Others data can
> > > be add of course and discussion is open about this subject (Arnd...).
> >
> > There is one important decision about the database:
> > Will it be possible to easily add additional fields
> >    - with new digikam releases (eg. 10.1, 10.2, ...)
>
> If you look at amarok, they have had about 20 schema revisions.
>
> We definitely plan to add more database fields. Adding a table with additional
> information is easy, it becomes more tricky if the change makes the database
> incompatible with previous versions. In this case, the application has to
> detect it and refuse to start.
>
> As current versions cannot do this, my current plan is to move the db file to
> digikam4.db (where 3->4 nicely coincides with KDE3/KDE4) and any version from
> now on will be able to refuse to start if it does not understand the schema.
> Users usually do not need to downgrade a version. If they have to, there'd be
> a severe regression which we should have fixed first ;-)
> So the possible missing compatibility (not for all schema upgrades necessary )
> mostly affects beta testers which might have a reason to use a stable
> version. In this case, we will make this clear in the release of beta1 - with
> schema changes only occuring in alpha state, and the option to specify
> different db files in config / on the command line.

Thanks for the detailed explanation - this looks like
a very robust, but still flexible path.

> >    - or even by the user
>
> The problem is that the application at least needs to provide means to read
> and write the added values. If it does not know at all about the nature of
> the data, this will be only very basic support.

Something like this might be possible via KROSS
(which would allow for simple plug-ins added by the user).

But: as you explained above, the new database will be much more
flexible and allow for additional fields, whenever they are
needed. Any new fields would also be accompanied by
code which makes use of them.
So I don't think that addition by the user is really needed.

Thanks a lot (and now I will stop asking about this, to not prevent
you from further coding ...),

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

Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:

> Hi all,
>
> See below the future digiKam plans :
>
> DIGIKAM 0.9.2 FINAL RELEASE:
> ---------------------------------------------
>
> The 0.9.2-final release date is near. Like Gerhard will back at home today
> (:=))), final release will be done at soon.
>
> Gerhard, just a little tip : the libkdcraw need to be released again
> following #146464 B.K.O file. the library have been patched to fix this bug.
> So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
>
> Angelo, Achim : Please take a care to provide a new package of this library
> for Mandriva and Debian at the same time than digiKam 0.9.2. thanks in
> advance...
>

hmm, the problem is that often i see that digikam has been released and then

i know it. Maybe in a case like this one we can talk, also in private, to get the
related libraries released first ;)

Ok, if you can wait for a day more, tonight i can release new libkdcraw tonight
and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the rc1 to get
final ready for the next week, but i haven't got the time to see the state of
bugs by now, and it depends on docs status anyway....

Is it ok for you?

Angelo

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

[Gerhard Kulzer]

Am Tuesday 12 June 2007 schrieb Angelo Naselli:

> Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > Hi all,
> >
> > See below the future digiKam plans :
> >
> > DIGIKAM 0.9.2 FINAL RELEASE:
> > ---------------------------------------------
> >
> > The 0.9.2-final release date is near. Like Gerhard will back at home
> > today (:=))), final release will be done at soon.
> >
> > Gerhard, just a little tip : the libkdcraw need to be released again
> > following #146464 B.K.O file. the library have been patched to fix this
> > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> >
> > Angelo, Achim : Please take a care to provide a new package of this
> > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > thanks in advance...
>
> hmm, the problem is that often i see that digikam has been released and
> then i know it. Maybe in a case like this one we can talk, also in private,
> to get the related libraries released first ;)
>
> Ok, if you can wait for a day more, tonight i can release new libkdcraw
> tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> rc1 to get final ready for the next week, but i haven't got the time to see
> the state of bugs by now, and it depends on docs status anyway....
>
> Is it ok for you?
>
> Angelo

Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
final with it.

Gerhard


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

[Colin Guthrie-6]

Marcel Wiesweg wrote:
> If you look at amarok, they have had about 20 schema revisions.

Yup. Easy upgrading is a must.

> We definitely plan to add more database fields. Adding a table with additional
> information is easy, it becomes more tricky if the change makes the database
> incompatible with previous versions. In this case, the application has to
> detect it and refuse to start.

If possible it may be nicer to enter a "read-only" mode where no changes
were permitted (to data or file) but the application would continue with
a warning to the user about the current state of play. Not sure how easy
this would be to implement so it's maybe not worth the hassle!

Still it would perhaps be nicer for the user should they find themselves
in that situation (I'm thinking ahead to when NFS mounted shares are OK
and users could conceivably login with different DK versions relatively
easily).

Col

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

Alle martedì 12 giugno 2007, Gerhard Kulzer ha scritto:

> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :
> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.
>
> Gerhard

I'm going to play with it just now and let you know.

Cheers,
        Angelo

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

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:

> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :
> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

 1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

 2) libkdcraw.mo files need to be installed as libkdcraw<abi-major>.mo. Again to
   allow libkdcraw0 and libkdraw1 installations at the same time.

   @Gilles: how are the translations loaded?  There no insertCatalog like in the
   old libkexif lib.

 3) release_*.rb needs to be adpated to the new layout in svn

Angelo and me will try to finish 2) and 3) Wednesday night.  Keep your fingers
crossed.

Sorry for the delay,
Achim
>
> Gerhard
>
>

Index: libkdcraw/dcraw/Makefile.am
===================================================================
--- libkdcraw/dcraw/Makefile.am (revision 674730)
+++ libkdcraw/dcraw/Makefile.am (revision 674731)
@@ -14,9 +14,11 @@
 # Note: dcraw project page is http://cybercom.net/~dcoffin

 bin_PROGRAMS = kdcraw
+bindir = $(KDCRAW_DIR)

-# The manual page of binary program.
-man_MANS = kdcraw.1
+# The manual page of binary program. (Don't install manpage of a library
+# internal helper app
+#man_MANS = kdcraw.1

 # This line is require to prevent broken compilation with -std=iso9899:1990 gcc option.
 # In fact, dcraw.c use lcms.h witch use the "inline" keyword witch do not exist in pure C
Index: libkdcraw/libkdcraw/dcrawbinary.cpp
===================================================================
--- libkdcraw/libkdcraw/dcrawbinary.cpp (revision 674730)
+++ libkdcraw/libkdcraw/dcrawbinary.cpp (revision 674731)
@@ -108,7 +108,7 @@

 const char *DcrawBinary::path()
 {
-    return "kdcraw";
+    return KDCRAW_DIR "/kdcraw";
 }

 bool DcrawBinary::isAvailable() const
Index: libkdcraw/libkdcraw/Makefile.am
===================================================================
--- libkdcraw/libkdcraw/Makefile.am     (revision 674730)
+++ libkdcraw/libkdcraw/Makefile.am     (revision 674731)
@@ -1,13 +1,12 @@
 METASOURCES = AUTO

-INCLUDES= $(all_includes)
+INCLUDES= -DKDCRAW_DIR='"$(KDCRAW_DIR)"' $(all_includes)

 lib_LTLIBRARIES = libkdcraw.la

 libkdcraw_la_SOURCES = dcrawbinary.cpp kdcraw.cpp dcrawsettingswidget.cpp

-libkdcraw_version_info = 0:1:0
-libkdcraw_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -version-info $(libkdcraw_version_info) -no-undefined
+libkdcraw_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -version-info $(VERSION_INFO) -no-undefined
 libkdcraw_la_LIBADD  = $(LIB_KDEUI) $(LIB_KDECORE) $(LIB_QT)

 libkdcrawinclude_HEADERS = rawdecodingsettings.h kdcraw.h dcrawbinary.h dcrawsettingswidget.h \
Index: libkdcraw/configure.in.in
===================================================================
--- libkdcraw/configure.in.in   (revision 674730)
+++ libkdcraw/configure.in.in   (revision 674731)
@@ -1,7 +1,20 @@
 AC_ARG_VAR(PKGCONFIGFOUND, [Path to pkg-config])
 AC_CHECK_PROG(PKGCONFIGFOUND, pkg-config,[yes])

+#-----------------------------------------------------------------
+# Library API version
 # -----------------------------------------------------------------
+
+ABI_MAJOR=1
+VERSION_INFO="1:0:0"
+
+AC_SUBST(ABI_MAJOR)
+AC_SUBST(VERSION_INFO)
+
+KDCRAW_DIR="\$(libdir)/libkdcraw\$(ABI_MAJOR)"
+AC_SUBST(KDCRAW_DIR)
+
+# -----------------------------------------------------------------
 # lcms check
 # -----------------------------------------------------------------



--
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [hidden email]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/6/13, Achim Bohnet <[hidden email]>:

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :

> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

2) libkdcraw.mo files need to be installed as libkdcraw<abi-major>.mo. Again to
   allow libkdcraw0 and libkdraw1 installations at the same time.

   @Gilles: how are the translations loaded?  There no insertCatalog like in the
   old libkexif lib.

Right ...

Note this problem exist too about libkipi witch include translation strings... About libkexiv2, there is no translations file... It's a pure low level C++ interface.

Well, this can be a problem with translations from libkdcraw and likipi. I'm so surprised than nobody have never reported this problem before...

If i take a look in branches/extragear/kde3/graphics, i can see than no kipi host program includes libkipi catalog for example (gwenview, kphotoalbum, showimg).

I can see only this line on digikam/digikam/main.cpp:

KGlobal::locale()->insertCatalogue("kipiplugins");

So my question is simple : has we need to have an insert catalog for libkipi and libkdcraw in kipi hosts ?

Gilles

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

[Gilles Caulier-4]

2007/6/13, Gilles Caulier <[hidden email]>:

2007/6/13, Achim Bohnet <[hidden email]>:

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :

> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

2) libkdcraw.mo files need to be installed as libkdcraw<abi-major>.mo. Again to
   allow libkdcraw0 and libkdraw1 installations at the same time.

   @Gilles: how are the translations loaded?  There no insertCatalog like in the
   old libkexif lib.

Right ...

Note this problem exist too about libkipi witch include translation strings... About libkexiv2, there is no translations file... It's a pure low level C++ interface.

Well, this can be a problem with translations from libkdcraw and likipi. I'm so surprised than nobody have never reported this problem before...

If i take a look in branches/extragear/kde3/graphics, i can see than no kipi host program includes libkipi catalog for example (gwenview, kphotoalbum, showimg).

I can see only this line on digikam/digikam/main.cpp:

KGlobal::locale()->insertCatalogue("kipiplugins");

So my question is simple : has we need to have an insert catalog for libkipi and libkdcraw in kipi hosts ?

Gilles

I have take a look in old libkexif library :

http://websvn.kde.org/tags/libkexif/0.2.5-final/

...where we can found 3 call of KGlobal::locale()->insertCatalogue("libkexif"); in widgets implementation...

I suspect than it's must be done in libkdcraw and libkipi...

Your viewpoints ?

Gilles


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

[Gilles Caulier-4]

2007/6/13, Achim Bohnet <[hidden email]>:

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :

> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

Achim,

in libkdcraw/libkdcraw/Makefile.am, this is not correct to use the macro :

INCLUDES = -DKDCRAW_DIR='"$(KDCRAW_DIR)"' $(all_includes)

The -DKDCRAW_DIR='"$(KDCRAW_DIR)"' sentence is not at the right place. You must use this macro instead :

INCLUDES= $(all_includes)
libkdcraw_la_CFLAGS  = INCLUDES= -DKDCRAW_DIR='"$(KDCRAW_DIR)"'

Gilles



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

[Gilles Caulier-4]

2007/6/13, Gilles Caulier <[hidden email]>:

2007/6/13, Achim Bohnet <[hidden email]>:

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :

> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

Achim,

in libkdcraw/libkdcraw/Makefile.am, this is not correct to use the macro :

INCLUDES = -DKDCRAW_DIR='"$(KDCRAW_DIR)"' $(all_includes)

The -DKDCRAW_DIR='"$(KDCRAW_DIR)"' sentence is not at the right place. You must use this macro instead :

INCLUDES= $(all_includes)
libkdcraw_la_CFLAGS  = INCLUDES= -DKDCRAW_DIR='"$(KDCRAW_DIR)"'

Oups sorry, wrong copy and paste. This is the right sentence :

INCLUDES= $(all_includes)
libkdcraw_la_CXXFLAGS = -DKDCRAW_DIR='"$(KDCRAW_DIR)"'

Compile fine here...

Gilles




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

Hi everyone,
      Just when I was thinking of starting a new thread in respect to Kipi-plugin under developement by me, I came to see this post. I think its relevant to ask my question in this thread.

This in regards to QT 3.3's limitation of not allowing HTTPS post needed for a new. QT 4.3 has support for HTTPS connection and so HTTPS post. My plugin is nearly done but I would like to use HTTPS connection for authentication purposes instead of HTTP post (both are allowed by the website, the post URL being an HTTPS one)

I see that kipi-plugins have started porting to KDE 4. Though none of the host application have done such a port. Doesn't this make the current development build of kipi unusable with host apps ? I have been stricktly using QT 3.3 for this fear. Should I just go ahead and start using QT 4, libraries and APIs ? [Is it okay to have a different QT library used for building libkipi, kipiplugins and another for Digikam ?]

Another question: Is there any other way, I can use QT 3.3 and get the https post functionality i.e by using another C++/C library just for HTTPS connection ? Does KDE have any extra support for https post (I have been using transferJob with http_post for http post and couldn't find any https_post method.)


Vardhman

On 6/13/07, Gilles Caulier <[hidden email]> wrote:

2007/6/13, Gilles Caulier <[hidden email]>:

2007/6/13, Achim Bohnet <[hidden email]>:

On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > Hi all,
> > >
> > > See below the future digiKam plans :

> > >
> > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > ---------------------------------------------
> > >
> > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > today (:=))), final release will be done at soon.
> > >
> > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > following #146464 B.K.O file. the library have been patched to fix this
> > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > >
> > > Angelo, Achim : Please take a care to provide a new package of this
> > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > thanks in advance...
> >
> > hmm, the problem is that often i see that digikam has been released and
> > then i know it. Maybe in a case like this one we can talk, also in private,
> > to get the related libraries released first ;)
> >
> > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > rc1 to get final ready for the next week, but i haven't got the time to see
> > the state of bugs by now, and it depends on docs status anyway....
> >
> > Is it ok for you?
> >
> > Angelo
>
> Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> final with it.

Hi Gerhard,

Angelo and me tried to get the tarball ready but did not finish.

The problems were/are:

1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
   so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
   674731)  See also: <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

2) libkdcraw.mo files need to be installed as libkdcraw<abi-major>.mo. Again to
   allow libkdcraw0 and libkdraw1 installations at the same time.

   @Gilles: how are the translations loaded?  There no insertCatalog like in the
   old libkexif lib.

Right ...

Note this problem exist too about libkipi witch include translation strings... About libkexiv2, there is no translations file... It's a pure low level C++ interface.

Well, this can be a problem with translations from libkdcraw and likipi. I'm so surprised than nobody have never reported this problem before...

If i take a look in branches/extragear/kde3/graphics, i can see than no kipi host program includes libkipi catalog for example (gwenview, kphotoalbum, showimg).

I can see only this line on digikam/digikam/main.cpp:

KGlobal::locale()->insertCatalogue("kipiplugins");

So my question is simple : has we need to have an insert catalog for libkipi and libkdcraw in kipi hosts ?

Gilles

I have take a look in old libkexif library :

<a href="http://websvn.kde.org/tags/libkexif/0.2.5-final/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://websvn.kde.org/tags/libkexif/0.2.5-final/

...where we can found 3 call of KGlobal::locale()->insertCatalogue("libkexif"); in widgets implementation...

I suspect than it's must be done in libkdcraw and libkipi...

Your viewpoints ?

Gilles


_______________________________________________
Digikam-devel mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="https://mail.kde.org/mailman/listinfo/digikam-devel" target="_blank"> https://mail.kde.org/mailman/listinfo/digikam-devel

--
Blogs: http://vardhman.blogspot.com

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

[Gilles Caulier-4]

2007/6/13, Vardhman Jain <[hidden email]>:

Hi everyone,
      Just when I was thinking of starting a new thread in respect to Kipi-plugin under developement by me, I came to see this post. I think its relevant to ask my question in this thread.

This in regards to QT 3.3's limitation of not allowing HTTPS post needed for a new. QT 4.3 has support for HTTPS connection and so HTTPS post. My plugin is nearly done but I would like to use HTTPS connection for authentication purposes instead of HTTP post (both are allowed by the website, the post URL being an HTTPS one)

I see that kipi-plugins have started porting to KDE 4. Though none of the host application have done such a port.

Gwenview is partially ported in KDE4:

http://websvn.kde.org/trunk/KDE/kdegraphics/gwenview/

But it do not include the libkipi interface port...

Doesn't this make the current development build of kipi unusable with host apps ?

I have been stricktly using QT 3.3 for this fear. Should I just go ahead and start using QT 4, libraries and APIs ? [Is it okay to have a different QT library used for building libkipi, kipiplugins and another for Digikam ?]

Mixing Qt3/Qt4 between kipi hosts and libkipi/kipi-plugins will never work...

Like libkipi and some plugins are already ported, i recommend to start KDE4 port in trunk as well and let KDE3. I have not yet tested the plugins ported : all compile fine only. To port code can take a while especially about to learn new API from QT4 and KDE4. Marcel and me we will trying to provide a first KDE4 port of digiKam during this summer... I recommend you to port your plugin as weel and wait than a host will be ported to KDE4 to start test and add new features...

Another question: Is there any other way, I can use QT 3.3 and get the https post functionality i.e by using another C++/C library just for HTTPS connection ? Does KDE have any extra support for https post (I have been using transferJob with http_post for http post and couldn't find any https_post method.)

I don't know. Why not to take a look in kflickr with use Qt3 ?

http://kflickr.sourceforge.net/wikka.php?wakka=Kflickr

Perhaps you can find a solution in implementation...

Gilles

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

Alle mercoledì 13 giugno 2007, Achim Bohnet ha scritto:

> On Tuesday, 12. June 2007, Gerhard Kulzer wrote:
> > Am Tuesday 12 June 2007 schrieb Angelo Naselli:
> > > Alle lunedì 11 giugno 2007, Gilles Caulier ha scritto:
> > > > Hi all,
> > > >
> > > > See below the future digiKam plans :
> > > >
> > > > DIGIKAM 0.9.2 FINAL RELEASE:
> > > > ---------------------------------------------
> > > >
> > > > The 0.9.2-final release date is near. Like Gerhard will back at home
> > > > today (:=))), final release will be done at soon.
> > > >
> > > > Gerhard, just a little tip : the libkdcraw need to be released again
> > > > following #146464 B.K.O file. the library have been patched to fix this
> > > > bug. So 0.9.2-final will need a new small 0.1.1 release of libkdcraw...
> > > >
> > > > Angelo, Achim : Please take a care to provide a new package of this
> > > > library for Mandriva and Debian at the same time than digiKam 0.9.2.
> > > > thanks in advance...
> > >
> > > hmm, the problem is that often i see that digikam has been released and
> > > then i know it. Maybe in a case like this one we can talk, also in private,
> > > to get the related libraries released first ;)
> > >
> > > Ok, if you can wait for a day more, tonight i can release new libkdcraw
> > > tonight and maybe a kipi-plugins rc1(?) beta2(?), I would have liked the
> > > rc1 to get final ready for the next week, but i haven't got the time to see
> > > the state of bugs by now, and it depends on docs status anyway....
> > >
> > > Is it ok for you?
> > >
> > > Angelo
> >
> > Can you give me a release hour for libkdcraw tomorrow? Then I can sync 0.9.2
> > final with it.
>
> Hi Gerhard,
>
> Angelo and me tried to get the tarball ready but did not finish.
>
> The problems were/are:
>
>  1) kdcraw binary needs to be installed into $prefix/lib/libkdcraw<abi-major>/kdcraw
>    so libkdcraw0 and libkdraw1 can be installed in parallel  (fixed with commit:
>    674731)  See also: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
>
>  2) libkdcraw.mo files need to be installed as libkdcraw<abi-major>.mo. Again to
>    allow libkdcraw0 and libkdraw1 installations at the same time.
>
>    @Gilles: how are the translations loaded?  There no insertCatalog like in the
>    old libkexif lib.
>
>  3) release_*.rb needs to be adpated to the new layout in svn
>
> Angelo and me will try to finish 2) and 3) Wednesday night.  Keep your fingers
> crossed.
>
> Sorry for the delay,
> Achim
> >
> > Gerhard
> >
> >
>
> Index: libkdcraw/dcraw/Makefile.am
> ===================================================================
> --- libkdcraw/dcraw/Makefile.am (revision 674730)
> +++ libkdcraw/dcraw/Makefile.am (revision 674731)
> @@ -14,9 +14,11 @@
>  # Note: dcraw project page is http://cybercom.net/~dcoffin
>
>  bin_PROGRAMS = kdcraw
> +bindir = $(KDCRAW_DIR)
>
> -# The manual page of binary program.
> -man_MANS = kdcraw.1
> +# The manual page of binary program. (Don't install manpage of a library
> +# internal helper app
> +#man_MANS = kdcraw.1
>
>  # This line is require to prevent broken compilation with -std=iso9899:1990 gcc option.
>  # In fact, dcraw.c use lcms.h witch use the "inline" keyword witch do not exist in pure C
> Index: libkdcraw/libkdcraw/dcrawbinary.cpp
> ===================================================================
> --- libkdcraw/libkdcraw/dcrawbinary.cpp (revision 674730)
> +++ libkdcraw/libkdcraw/dcrawbinary.cpp (revision 674731)
> @@ -108,7 +108,7 @@
>
>  const char *DcrawBinary::path()
>  {
> -    return "kdcraw";
> +    return KDCRAW_DIR "/kdcraw";
>  }
>
>  bool DcrawBinary::isAvailable() const
> Index: libkdcraw/libkdcraw/Makefile.am
> ===================================================================
> --- libkdcraw/libkdcraw/Makefile.am     (revision 674730)
> +++ libkdcraw/libkdcraw/Makefile.am     (revision 674731)
> @@ -1,13 +1,12 @@
>  METASOURCES = AUTO
>
> -INCLUDES= $(all_includes)
> +INCLUDES= -DKDCRAW_DIR='"$(KDCRAW_DIR)"' $(all_includes)
>
>  lib_LTLIBRARIES = libkdcraw.la
>
>  libkdcraw_la_SOURCES = dcrawbinary.cpp kdcraw.cpp dcrawsettingswidget.cpp
>
> -libkdcraw_version_info = 0:1:0
> -libkdcraw_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -version-info $(libkdcraw_version_info) -no-undefined
> +libkdcraw_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -version-info $(VERSION_INFO) -no-undefined
>  libkdcraw_la_LIBADD  = $(LIB_KDEUI) $(LIB_KDECORE) $(LIB_QT)
>
>  libkdcrawinclude_HEADERS = rawdecodingsettings.h kdcraw.h dcrawbinary.h dcrawsettingswidget.h \
> Index: libkdcraw/configure.in.in
> ===================================================================
> --- libkdcraw/configure.in.in   (revision 674730)
> +++ libkdcraw/configure.in.in   (revision 674731)
> @@ -1,7 +1,20 @@
>  AC_ARG_VAR(PKGCONFIGFOUND, [Path to pkg-config])
>  AC_CHECK_PROG(PKGCONFIGFOUND, pkg-config,[yes])
>
> +#-----------------------------------------------------------------
> +# Library API version
>  # -----------------------------------------------------------------
> +
> +ABI_MAJOR=1
> +VERSION_INFO="1:0:0"
> +
> +AC_SUBST(ABI_MAJOR)
> +AC_SUBST(VERSION_INFO)
> +
> +KDCRAW_DIR="\$(libdir)/libkdcraw\$(ABI_MAJOR)"stt
> +AC_SUBST(KDCRAW_DIR)
> +
> +# -----------------------------------------------------------------
>  # lcms check
>  # -----------------------------------------------------------------
>
>
>

it seems i've sent my mail only to Achim last night :(
I've uploaded new tarball without localization
http://www.linux.it/~anaselli/kipi-plugins/libkdcraw-0.1.1.tar.bz2
Please test it. I believe we can release a new one with localization
in a couple of days at the latest.

WDYT?
        Angelo

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