[Digikam-devel] Future plans : 0.9.2-final and KDE4 port...

Gilles Caulier caulier.gilles at gmail.com
Mon Jun 11 12:38:00 BST 2007

Hi all,

See below the future digiKam plans :


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


The future KDE3 digiKam release will be a bugfix release. No new features
will be added. The code will still into

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 digikam-devel at kde.org 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.


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 (
- 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.0release 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


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


- 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

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...


Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070611/f711e766/attachment.html>

More information about the Digikam-devel mailing list