digiKam 5.0.0 is published…

Dear digiKam fans and users,

After two year of work, the digiKam team is proud to announce the final release of digiKam Software Collection 5.0.0. This main version introduces a new cycle of releases, which will be shortly released to quickly include all the fixes reported by end users.

This release marks almost complete port of the application to Qt5. All Qt4/KDE4 code has been removed and many parts have been re-written, reviewed, and tested. Porting to Qt5 required a lot of work, as many important APIs had to be changed or replaced by new ones.

In addition to code porting, we introduced several changes and optimizations, especially regarding dependencies on the KDE project. Although digiKam is still a KDE desktop application, it now uses many Qt dependencies instead of KDE dependencies. This simplifies the porting job on other operating systems, code maintenance, while reducing the sensitivity of API changes from KDE project.

The goal in the future is to be able to provide a pure Qt5 version of digiKam. This is not possible currently as digiKam has a big legacy with KDE. At least, 80% of KDE dependencies have been removed, 10% become optional for Linux Desktop, and the rest still mandatory for the moment. Included in this huge task to reduce dependencies, we have ported digiKam KIO-slaves to a multi-threaded interface, reduced the Dbus use to Linux desktop, and dropped KIO usage in Kipi tools.

The consequence of limiting external dependencies is to open quickly the way to port code to non-Linux platforms and to provide binary installers. The first one is the Windows port which is now done through MXE project by cross-compiling with MinGW. We don’t use now a Windows/MSVC couple to compile and build the installer. All is done automatically under Linux by a series of bash scripts. 32 and 64 bits installers are provided. The result is an improved, better and more stable digiKam than before under Windows.

The other installer automatically generated by scripts is OSX packages. This one still needs an Apple computer with Macports, but the compilation is really simplified now. Here again, The result is a more stable digiKam than before under OSX.

As a part of code optimization, an important task was done by Mohamed Anwer, a long-term contributor to digiKam. He worked last summer during “Google Summer of Code” to remove all digiKam KIO-slaves used to query the database. Instead, a robust multi-core/multi-threaded implementation is now used. digiKam had introduced KIO-slaves when the first SQLite database support was implemented. The goal was to perform database-related actions (processing searches, listing albums, tags and dates, storing detected faces, etc) in the background without getting a non-responsive graphical interface. As the first version of SQLite did not support multi-threading, using KIO technology was the best solution. Although this worked fine, it became evident that using separate processes was very sensitive with each systems update and was not portable to non-Linux systems. The new solution is also faster because it does not use data serialization shared between digiKam and KIO-Slaves.

Since removing KIO-Slaves was faster than planned, Mohamed also implemented a new important feature: the virtual digiKam trash folder.
Previously, digiKam used the KDE desktop trash, which couldn’t be ported to Mac OS X and Windows. Also, in the case of the KDE desktop trash, deleted items were removed permanently from the computer instead of being moved into the desktop trash -- which was not an acceptable solution. Now, like all commercial photo management software, digiKam uses a hidden subdirectory in each main collection (including removable ones) to store deleted items. The trash is accessible from the album tree view, and the user can restore or delete items permanently as they wish. This is a simple, user-friendly, and portable solution.

Last summer, another long-term digiKam contributor, Veaceslav Munteanu, worked to improve the metadata workflow in digiKam, especially for synchronizing photo metadata with the database contents. A typical use case here is to queue all changes to process files when you change metadata in the digiKam interface. The database is patched, but not the metadata. As this last operation can take a while, we delegate pending operations to a new tool named Lazy Synchronization tool, which will do the job when the user decides, or at the end of a digiKam session. In the status bar, you can see if pending items need to be processed by the tool.

In addition to a new settings panel, where the user can tune the Exif/IPTC/XMP tags to handle database population with key image information, like date, comments, keywords, rating, etc., Veaceslav also worked on another part of metadata management. It’s now possible to order tags to parse while items parsing and specify which tags will be updated in the image using the Lazy Synchronization tool.

Shourya Singh Gupta from India worked exclusively on porting on export tools to Qt5, factorizing lots of duplicate code everywhere, optimizing the implementations, performing tests, and reviving old plugins which have not had maintainers for a very long time. He helped to quickly have a suitable code working with Qt5. This allowed the team to drop the last Qt4 dependencies. In a parallel, Maik Qualmann has ported all Kipi tool to pure Qt5 in the way to drop the use of KIO API to talk with remote web services. This will make Kipi tool suitable on non-Linux desktop as KIO require a lot of run-time dependencies which make digiKam unsuitable or unstable.

Another important part on which the team is working for the next 5.0.0 is MySQL/MariaDB interface.
The whole database code has been reviewed, polished, cleaned, and documented. The face recognition database is now integrated into the digiKam core and is stored in SQLite or MySQL.

The MySQL interface was written 5 years ago by a contributor who had left the team since then. This code was placed in quarantine due to the lack of support and bugs. But thanks to the new MySQL expert on the team, we are now able to restore, fix, and improve this functionality step by step.

Richard Mortimer has proposed lots of patches to fix and rewrite MySQL database schemas aiming to have a compatible digiKam database with the last MySQL or MariaDB default engine. New database features have been introduced and the database configuration panel has been re-written to ensure safety during database server configuration stage.

It’s now possible to setup a MySQL database at first run, instead of using SQLite first and migrating to MySQL later.
Two Mysql servers are available:

• Local one to replace local SQLite storage
• Remote one to use a shared computer through the network

MySQL offers many advantages for storing digiKam data, especially when collections include more than 100,000 items. With such large collections, SQLite introduces latency which slows down the application. With this new release, you will be able to host MySQL internal server database files at a dedicated place, as with SQLite. Keep in mind that MySQL support is still under development and is not yet fully suitable for production. The database schemas are not yet fully patched, and lots of regression tests are yet to be performed.

This summer, Swati Lodha will focus on working exclusively on database interface, to improve MySQL support in case of multi-accounts (photo agency use cases), and fix a lots of pending bugs reported by end users since a very long time.

Also this summer as part of Google Summer of Code, Omar Amin will work on implementing a tool for automatic red-eye detection and correction to be added to Batch Queue Manager (BQM) and adding a tool to the Image Editor for manual red-eye correction.

For further information, take a look into the list of more than 375 files currently closed in Bugzilla.

digiKam software collection source code tarball, OSX (>= 10.8) package, and Windows 32/64 bits installers can be downloaded from this repository

Happy digiKaming!