Porting KIPI-Plugins and Libkipi to KDE XML-GUI

Porting KIPI-Plugins and Libkipi to KDE XML-GUI

Name: Victor Dodon
Email:dodonvictor@gmail.com
IRC Nick: printesoi
Location: Bucharest. Romania. Splaiul Independentei nr.290
Proposal title: Port kipi-plugins and libkipi to KDE XML-GUI, mentors Gilles Caulier and Angelo Naselli.

Motivation for proposal: digiKam is a very powerful and successful photo management program. It’s very dynamic and new features are added continuously. But there are some parts of the program that are quite old and need to be rewritten to be up to date, more flexible and more powerful. One of these is the kipi-plugins architecture, shared through libkipi with other kipi-host applications such as Gwenview or KPhotoAlbum. It uses a difficult and hard-coded way to plug actions in GUI, which is not flexible and need recompilation of the code.
My goal is to reimplement the kipi-plugins architecture using KDE XML-GUI and to patch all the plugins, libkipi and other kipi-host applications in order to support it and to find a solution that will provide a way to customize menu for each plugin. KDE XML-GUI offers a very flexible way to control how and where menu actions and toolbar icons are inserted in the UI, using XML files loaded at runtime and it automatizes well plugins mechanism. I think that is important for digiKam (and for the other kipi host applications) to replace the deprecated architecture with a new one (like the plugin architecture used in the image editor) to become able to host and manage all kipi-plugins actions into standard application toolbar.
This proposal is based on an old entry in the KDE bug-tracker - 122454, so this is a requested feature that hasn’t been solved and is still open. Was requested the availability of kipi-plugins as buttons for the toolbar, feature that can be accomplished using the XML-GUI toolkit, that has performed very well for the image editor.

Implementation details:
As Gilles Caulier stated, to finish successfully this task I will need to follow some steps.

1. Patching libkipi shared library
This first step is the most important and difficult because libkipi is hosted in the KDE core and is released through KDE release, so I need the follow KDE release plan. To accomplish this task I will need to patch/reimplement two classes: KIPI::Plugin (plugin interface for all kipi-plugins) and KIPI::PluginLoader (the class that helps host applications to load plugins). Another important point is that I need to maintain the backward compatibility with the current deprecated plugin architecture.

2. Patching digiKam kipi interface
digiKam kipi interface contains a collection of re-implemented classes from libkipi, including the plugin loader (the class Digikam::KipiPluginLoader) that must be patched to support the new architecture. The old one must be preserved for compatibility with older libkipi releases.

3. Patching all the kipi-plugins
It will be necessary to patch all the plugins that use the old architecture in order to support the new one.

4. Patching other kipi host applications
In this step I’m supposed to propose patches for Gwenview, KSnapshot and KPhotoAlbum. I will need to contact the teams that develop these apps to find a solution that fits every application, but remaining as generic as possible.

In my implementation, I will take as reference the code used for the image editor, which is based on the KDE XML-GUI architecture. After inspecting the code, I can tell that things are done in a simpler way that in libkipi and we all know that things that are simpler are more powerful and are sources of less bugs.
When implemented in the KDE XML-GUI architecture, plugins will provide default XML configuration files that will need to be adapted to digiKam album GUI structure, but because other kipi host applications use a different menu layout, the patch must let host application to customize these XML files.
As I stated above, I need to follow the KDE release plan for the libkipi share library. I will try to finish the patch for libkipi before KDE 4.8.4 will be released (5th of june), if this will not be possible, I will try before KDE 4.9 Release Candidate 1 Tagging (june 26).
A very important and also critique point in this project is the customization of the menus where are inserted the kipi-plugins in the host-application. As I already said, the plugins will provide default XML configuration files. The technique used for building the application GUI using KDE XML-GUI is based on merging the entries defined in those XML files (the files itself are not merged, only the GUI). Sounds awesome (and in fact it really it) but there is an important aspect: the kipi-host application must control how and where menu entries and toolbar icons are merged.  Fortunately, KDE XML-GUI technology offers several ways to control the details of merging (according to [1]): using <Merge>, <DefineGroup> and <ActionList> tags. Another great thing is that this technology allows to insert a group of actions at a particular point in the GUI at runtime and supports dynamic lists of actions, thus allowing the creation of dynamic menus ([2]).
To prove that this idea can be implemented I created two little examples that I keep in my Github account here (instructions to run the examples can be found in the README). You can see that the C++ code is identical in both “example2” and “example3”, differ only XML configuration files and the UI now is different. “Example2” use the default behavior of the merging, but “Example3” uses <DefineGroup> tag to change the order of the menus and of the entries. This shows that we can let kipi-host applications to edit XML files that kipi-plugins will provide to create its own graphical layout. Also the examples show how easy is to plug actions in the main toolbar either with the XML files, or just by right-clicking over the menu action and selecting “Add to toolbar”.

Expected results:
After finishing the project the kipi-plugins architecture will be re-implemented using the KDE XML-GUI technology. Each kipi-host application will be able to customize the menu actions of the plugins to fit its own layout. Users will be able to add kipi-plugins buttons to the digiKam toolbar so they will be only one click distance to their favorite plugin (instead of two), this way being able to hide the menu bar even if they use often kipi-plugins (that are the only components in the album GUI that can’t be plugged in the toolbar).
To be more suggestive I made some mockups of how will look, for example digiKam, after finishing the project and patching libkipi and kipi-plugins to support KDE XML-GUI technology.

• digiKam with plugin actions plugged in the toolbar (icons and text) (full-size)

• the same, icons only (full-size)

• an action with a drop-down menu(Export to and Import from Facebook) (full-size)

Tentative timeline:
April 24 - May 21 : Getting in touch with developers of all the kipi-host applications and discussing in order to find a solution that will fit as well as possible all the apps and with the KDE release team to find the best solution for synchronising the development of the new plugin architecture with KDE core.

May 22 - June 26 : Patching libkipi before the release of KDE

June 27 - July 15 : Patching digiKam kipi-interface and all the kipi-plugins

July 16 - August 13 : Making patches for other kipi-host applications following the solutions as discussed with the developers of the kipi-host applications.

August 14 - … : Improving and testing the code. If it will be possible to finish earlier I would like to implement some bonus features

A graphical representation of the timeline (full-size):

Do you have other obligations from late May to early August? My exam session begins 18th of may and ends 8th of june. Only during this period I will have less time for the project. For the rest of the time I can give all my time for the project.

About me: I am a 2nd year undergraduate student and I study Computer Science at “Faculty of Automatic Control and Computers” at “POLITEHNICA” University of Bucharest. I am very passionate about Computer Science and especially about operating systems, software engineering and recently I started to like hardware design. I have 2 years of experience with C and C++ languages,1 year with Java and Ruby  and I am already familiar with Qt framework, KDE Api and with GIT SCM. I have participated in the free Open Source Development Course (in romanian CDL), a course organized by ROSEdu (ROmanian Open Source Education) where I made my first contribution to an open source project - digiKam. I refactored the metadataedit plugin by merging three dialogs(for editing IPTC, XMP and EXIF metadata) into a single dialog with three tabs. Recently I developed a new kipi-plugin that let users to export photos to ImageShack web service(closed entry 233926). Now I have an official KDE developer account because I want to be a long term KDE developer.
I think I’m suitable because I’m already familiar with all used technologies and with the current plugin architecture and implementation details, so I have all the prerequisites and I will spend no time to get used with the digiKam code. I will need to get used only with the code of other kipi-host applications. Also, I love programming (especially in C++ language), I learn fast and I’m hardworking.

Minimum time involvement estimation:
April 24 - May 17 : 25 - 30 hours per week
May 18 - June 8  : 15 - 20 hours per week (this is the exam period)
June 9 - August 20 : 40 - 45 hours per week