digiKam | GSoC 15 the summary


I know it’s been too long, I should have written something about my GSoC project with digiKam and how it was going, But actually I was too busy discovering new parts of digiKam source code, By the way, the source code of digiKam is not small it’s 1,079,949 lines of code and increasing every day, also most of my work was away from GUI, so I had no screenshots 🙂

My project was about increasing the performance, portability, and reliability, the project goal was to drop all KIO-Slaves which were created to do DB calls in a separate process and get the results to digiKam app, But why would we drop them if they were working just fine, here is why:

  • They were creating some malfunctions on Windows, so they affect the portability
  • They need data serialization, So you see data converted to QByteArrays everywhere in the code, Which was creating some performance issues
  • KIO-Slaves are working in separate processes, Which were impossible to debug and fix

Now the new implementation is thread based, and everything is done in a single thread, No data serialization anymore, and everything is faster.

Also, the project intended to create a safe way to isolate KIO implementations everywhere in the source code which represents in big part in the code, So I created a wrapper called KIOWrapper, which holds every single file include and method call related to KIO in it, But why isolating them?!, Simply now we can create a CMake flag to make digiKam a pure Qt implementation.

But wait a minute, How can we now do stuff with file system like copy and delete when KIO implementation is isolated and turned off, Simply I created a new thread based implementation to do all IO jobs, like file deletion for example, Just mark a bunch of images in digiKam view, right click on one, then press delete, Now you are creating a number of jobs (tasks) equal to the number of images, and those jobs get appended to the jobs que.

The best part of the project

It was a surprise for me too 🙂 , When I was wrapping KIO code, I found some code which was meant to handle deleting files to trash, So I had to create an equivalent trash implementation, But my mentor Gilles Caulier suggested creating a special trash implementation for digiKam, So there will be a trash for every image collection, Here is a screenshot to illustrate my words


As you can see in the screenshot there is a separate virtual album to see items in your trash for this collection and this album is added for every collection you have on you computer, also, you can see a nice table view showing the relative path which represents the place the image will be restored to, and of course you see the deletion timestamp,

Of course, you can discover everything about it intuitively from the screenshot, Have fun!

Randa Meeting 2015

There is a lot of work to do and a lot of surprises to reveal, Specially when it comes to Android 🙂 , This year digiKam team will attend the Randa meeting to meet up together trying to do their best to introduce Android ports for digiKam,

To learn more about the event please check this link, and don’t hesitate to donate to make this really happen, Thanks in advance.


2 thoughts on “digiKam | GSoC 15 the summary

  1. Frank says:

    You mention that on file delete a thread is started for each file. IMHO this does not scale very well if many images are going to be deleted (thread creation is slow). A better solution would be to queue file-delete tasks to a fixed number of threads (aka thread pool)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s