Looking for maintainers for a few KIPI plugins

For the past few months I haven’t been able to find enough time and motivation to work on the two KIPI plugins I am supposed to maintain: HTML Export and Batch Image Processing.

I think it’s time for me to acknowledge that I am doing a disservice to users by lagging on bug reports and being practically inactive. This probably come from the fact that I do not have a personal need for these plugins, so it would be better for them to find maintainers who really care about them.

In case you don’t know about it, KIPI stands for KDE Image Plugin Interface. It is a library which makes it possible to share plugins between imaging applications. As far as I know, KIPI plugins are used by digiKam, KPhotoAlbum and Gwenview.

Right now most KIPI plugin developers are also digiKam developers, which is the reason it took me so long to decide giving up on the plugins I (am supposed to) maintain: it did not feel fair to let digiKam developers indirectly work for Gwenview without giving something back to digiKam.

The “Batch Image Processing” and “Raw converter” plugins (also in need of a maintainer) are going to be disabled in the next version of digiKam because digiKam is going to provide more tighly integrated implementations of these tools (see Gilles post about Batch Queue Manager). This is why it is very important to get new developers involved: no one can expect digiKam developers to maintain plugins which are not available in their application.

KIPI plugins are usually small code bases, which can be relatively easy to grasp for a newcomer. Working on a KIPI plugin is also a great way to contribute to several applications at a time! Of course I intend to help new maintainers getting used to the code bases as much as I can. If you are interested, join the kde-imaging mailing list and get started!

StatusNotifierItem and DBusMenu

One of the projects my team at Canonical is working on is a GNOME implementation of the StatusNotifierItem spec created by Plasma developers, as well as another spec named DBusMenu. The goal of DBusMenu is to make it possible for applications using the StatusNotifierItem spec to send their menus over DBus, so that the workspace can display them in a consistent way, regardless of whether the application is written using Qt, GTK or another toolkit.

As the KDE guy of the team, I have been working on implementing DBusMenu for KDE. It is still very much a work in progress, but it’s starting to take shape. Here is a screencast of what it looks like so far:

Download original

As you can see, it still needs a lot of work, for example support for menu titles is not there yet and Rhythmbox icons are not found (surprisingly, KDE does not ship with “gtk-quit” or “gtk-media-next” icons ). But it’s starting to be usable, and I find it nice to get a Plasma-themed menu when I right-click on the Rhythmbox icon! It’s also nice to get mouse over effects on this icon as well (it’s not very visible in this video, but look at the Rhythmbox icon at 0:27)

This definitely won’t be part of KDE 4.4, but hopefully should be ready for 4.5. For now the KDE part of this work is hosted on KDE Subversion server, in a work branch: branches/work/~agateau/dbusmenu.

PS: The version of Rhythmbox you see in this screencast comes from the Personal Package Archive (PPA) Ted mentioned in his post.

PPS: Should you be interested in trying this, contact me because for now you need special versions of libdbusmenu and libappindicator (the libraries behind the GTK implementation) for the icon and menu to show up in KDE System Tray applet.

Update: Moved video to blip.tv because vimeo.com does not allow downloading the original if one does not have an account.

Tip of the day: Finding the source of a bad_alloc exception

Quick tip of the day.

Today I was debugging a bad_alloc exception, but the backtrace was useless because the exception was being rethrown by Qt event loop.

After some head scratching, I figured this simple trick which you may find useful:

b 'std::bad_alloc::bad_alloc()'

This sets a breakpoint on bad_alloc constructor. After restarting the program, I was able to get a much more useful backtrace.

Hope this helps!

Introducing Colibri, an alternative to Plasma notifications

One of the features I worked on for Kubuntu 9.10 (Karmic Koala) was an implementation of Ayatana notifications for Plasma. Ayatana notifications are passive (without buttons) notifications which are queued instead of stacked. An interesting feature of these notifications is that when you move your mouse over them, they fade away and let you click through them, making it possible to interact with the window below.

In Kubuntu 9.10, Ayatana notifications for Plasma are implemented as a patch against the systemtray applet (go to the systemtray configuration to enable them). This was accepted by the Kubuntu developers as an experiment, not as a permanent change, because the Kubuntu devs prefer to follow upstream KDE as much as possible. As a consequence, I was told the patch implementing Ayatana notifications would not be present in the next version,  Kubuntu 10.4 (Lucid Lynx), because the idea of passive notifications does not fit with Plasma team vision.

I initially was skeptical about passive notifications, but it grew on me and I didn’t want to loose them. From the feedback I received, quite a few people like them as well. For this reason I decided to turn my patch into a standalone implementation: Colibri, which should hopefully be packaged in Kubuntu 10.4 and can be more easily installed and packaged for other distributions as well.

The code is hosted on Gitorious. Yesterday I released the first version on kde-apps.org. Colibri is composed of a binary and a (very rough) module for System Settings.

Give it a try!

Gwenview Importer

I have been quite quiet on Gwenview front lately, getting a job which does not involve two hours in a train everyday and becoming a father for the second time apparently does not help to find free time to hack (how surprising!)

Still I managed to get some work done on the start page and fixed a few bugs here and there. The main improvement though is the implementation of an importer for Gwenview, based on some previous experiment.

Its aim is to require as little manipulation as possible to get your pictures and video imported from your camera. It integrates with Solid so starting the import is just a matter of plugging in your camera/inserting your memory card, and selecting “Download Photos with Gwenview” from the popup which opens. You are then presented with a thumbnail view like the following, where you can select the documents to import as well as the import destination (destination is remembered across imports and defaults to ~/Pictures or whatever xdg defines):

Clicking “Import Selected” or “Import All” imports the documents to your destination folder. When it is done, the import asks you what to do with the documents on the device.

Once you clicked either “Delete” or “Keep”, you get this final page:

Whenever possible, the importer tries to be smart. For example it automatically goes inside folders as long as they are alone in the hierarchy, so if your pictures are all in /DCIM/FOOBAR/, it will go into this folder directly instead of showing you a single DCIM folder, then a FOOBAR folder. On the other hand, it won’t scan the whole device recursively, which could be quite painful if you just plugged a large external hard drive…

Another example is handling of already imported documents. Gwenview Importer will tell you if it skipped documents which have already been imported or if it renamed documents to avoid overwriting existing ones. For example if I select “Keep” in the “Delete or Keep” dialog and in a next import select the 3 imported documents as well as 2 new documents, I get this message (The wording can probably be improved, please send suggestions…):

Yet another point where the importer tries to be smart is on the name of the imported documents. Nothing is less useful than a series of pictures named PICT0001.JPG, PICT0002.JPG… so by default Gwenview Importer renames your pictures using the shooting date. This can be configured by clicking on the “Settings” button from the thumbnail page, which brings this configuration dialog:

I spent quite some time working on this formating thing. I tried to make it easy to customize the rename format by:

• providing a preview of the output,
• using words instead of single letter variables (ie {date} instead of %d),
• making the list of available variables with their description always visible,
• making the variable names clickable, so that you can easily insert them

It’s not as good as what Mac OS X can do, but I hope it is easy enough nevertheless. If I get the time to work a bit more on this (read: unlikely to happen :/), I think highlighting the variables in the line edit would be nice.

That’s all for now. Tell me what you think of this.

Yokadi 0.11.0, err 0.11.1 is out!

After quite some work, we are proud to announce a new release of Yokadi, the command-line driven, geek friendly, sqlite backed TODO list. This new release brings quite a few changes compared to 0.10. Quoting the announcement:

Version 0.11.0 brings you a much nicer t_list output:

• The width of the title column now adjusts itself to fit your terminal width and the content to display.
• Task keywords are now printed in the title column.
• Using the new -k switch, you can group tasks by keywords instead of grouping them by project.

0.11.0 also brings you a few handy shortcuts:

• Special character ‘_’ can be used to represent last task id in all task commands: handy to add a due date after adding a task: just type “t_due _ tomorrow” to set the last used task due date to tomorrow.
• Custom aliases can be defined for all commands with a_add.

Other changes:

• Bugs keywords are prefixed with a ‘_’ to distinguish them from user keywords.
• YOKADI_DB environment variable can be defined to set default yokadi database path.
• Switch from “GPL v3” to “GPL v3 or newer” license.

Version 0.11.0 also contained a silly last-minute mistake, hence the blog title, but it’s all fixed now, get it!

New addition to my life: Antonin

Yesterday evening, at 21:21, Antonin realized staying inside his mother was no longer possible and decided to explore a new world, ours.

Everything went very well. Baby and mother are OK. Antonin’s sister is eagerly waiting for them to come back home and his father better hurry up assembling his wardrobe and bed (he was expected to arrive at the end of the month, not the beginning!).

As a father of a new born baby, I think you can trust my words when I tell you he is the cutest baby on earth (even if I may have already written something similar, 3 and a half years ago). But should you doubt it, here is the proof:

Yes, his hat is a bit large

Indicators, notifications and co

Introduction

Jonathan post about indicators has been received with various feelings, ranging from interest to questioning or plain hostility. Since I get more and more people asking about this indicator thing, I figured I should try to explain what indicators are, how they are different from notifications and answer a few other frequently asked questions.

Disclaimer: The opinions of this post are my own, they do not necessarily reflect Canonical position.

Indicators for the user

Indicators are a way to get permanent informations, rather than ephemeral ones like notifications. I find it easier to explain the difference with use cases.

Imagine you receive an incoming message from your IM client while you are away from your machine. A notification gets shown, but this notification goes away after a few seconds. You just missed it.

Since the IM client supports indicators, it also created an indicator for this incoming message. When you come back to your desk, you notice the spark on the indicator plasmoid. Clicking on the plasmoid popups a menu listing all indicator-enabled running applications. Below your IM application entry, there is an entry for this incoming message you received. You click the entry and the chat window is brought to the front.

You would also like to know if you have any unread message in this “From Boss” mail folder. So you look at the mail client entries, and notice that “From Boss” appears, with a count of 2. You click the “From Boss” entry and your mail client is brought to the front, showing the first unread message in the “From Boss” folder.

You are now busy working on this report due to your boss for yesterday. You turned your status to “Busy, Do not Disturb, Will Bite”, but that does not stop people from sending messages to you. If your IM client is smart enough, it can disable notifications and only create indicators. When your report is finally done, you can relax, click the indicator plasmoid and start chatting with the people who tried to reach you before.

Back home, you decide to spend the evening watching a movie on your laptop. Since you are running a fullscreen application, notifications are disabled: you do not want to get interrupted by this IRC message from your friend while Bruce Willis is busy saving the world. When world has been saved, you can click the indicator and catch-up with your friend.

Indicators for the application developer

libindicate-qt provides two objects for the application developer: QIndicate::Server and QIndicate::Indicator.

The application typically starts with instantiating a server, declaring its desktop file and “server type” (a way to group applications, for now the plasmoid only shows servers with the “messaging” type), then calling the show() method. As soon as this is done, an entry for the application appears in the indicator menu. When the user clicks on this entry, QIndicate::Server emits the serverDisplay() signal. All you have to do is to connect to this signal and bring your main window to front.

When an event worth mentioning to the user happens, you instantiate a QIndicate::Indicator for it. An indicator can have a few properties:

• name: the text to display
• icon: a QImage for your indicator
• time: a QDateTime describing the time of the event, if relevant
• count: an int representing a count, if relevant
• draw_attention: a bool which must be set to true for the plasmoid to display its spark

“time” and “draw_attention” are useful for indicators representing events like IM messages, while “count” can be used for example by mail clients to create indicators for their folders.

When the user clicks on the indicator entry, QIndicate::Indicator emits a display(QIndicate::Indicator*) signal. Connect to this signal to perform the action relevant to this indicator.

(Note: the properties listed here are those used in the case of messaging communication, but the Indicator API is flexible enough to let you define other indicator properties)

FAQ

Couldn’t this be implemented within KDE notification system?

The KDE notification system can represent notifications in a few ways: showing popups, playing sounds, writing to log files, running programs…

I tried to implement support for indicators as a new way for the notification system to represent notifications, but it did not work because the notification system lacks the server/indicator structure. For example to implement the feature which brings the application to front when you click its entry, I ended up having to remember the window id of the first notification I received so that I could bring back this window. It was unreliable (what if the first window was gone by that time, or even not specified?) and it was not possible to do things like showing a count of unread emails in a folder for example.

Couldn’t this be implemented with KNotificationItem?

KNotificationItem is a new xdg specification which aims at replacing the SystemTray specification. Quoting the specification itself: “It is intended to be complementary but not directly related with the Freedesktop’s Desktop Notifications specification and is aimed as a replacement to the Freedestop System tray specification.”

In short, it is system tray done right. It is a huge step forward as it makes it easier for the application/toolkit to implement system tray support and it makes it easier for the system tray host to display these icons in a way which is consistent with the rest of the desktop interface.

It expands on the system tray spec by introducing a notion of status (Passive, Active and NeedsAttention), a possible icon overlay and a category (ApplicationStatus, Communications, SystemServices and Hardware).

It has a few features indicators do not have, such as tooltips and support for right-click, middle-click and mouse wheel events.

It does not however provide an equivalent to the server/indicator structure, or to the “count” and “time” properties. This makes it impossible to implement indicators on top of KNotificationItem.

Still, the two systems have quite a few commonalities, so it may make sense to merge them in the future.

Where does it come from?

libindicate has been developed by Canonical Desktop Experience team, as part of the Ayatana initiative. Ubuntu 9.04 (Jaunty) was the first version of Ubuntu to feature it on the GNOME desktop.

The upcoming Ubuntu 9.10 (Karmic) expands on this by providing a Qt binding for libindicate, adding support for indicators to a few Qt and KDE applications and a plasmoid to display indicators on the KDE desktop.

Is it Ubuntu specific?

No. The Canonical Desktop Experience team considers itself as an upstream developer team. As such we release source tarballs, which are then packaged by Ubuntu, but can be packaged by other distributions as well.

Here are the links to download them:

• libindicate
• libindicate-qt

Does it depend on GTK+?

libindicate-qt depends on libindicate. libindicate used to depend on GTK+ at runtime, but it’s not the case anymore.

It still depends on GTK+ at build time because compiling libindicate from source produces libindicate.so and libindicate-gtk.so. libindicate.so depends on GLib, but does not depend on GTK+. I recon depending on GTK+ to build the library is a problem for source-based distribution like Arch Linux or Gentoo, patches from autotools masters are welcome. A bug has been filled to track that issue.

It is a cross-desktop system: indicators from KDE applications show up in GNOME indicator applet, indicators from GNOME applications show up in KDE plasmoid.

What applications support it?

On the KDE side:

• Quassel
• KMail
• Konversation
• Kopete

Upstream processes for these patches are in various states. Quassel patch is already in their git repository, Konversation patch has been submitted but needs some work, KMail and Kopete patches have not been submitted yet.

You can find all the patches here.

On the GNOME side:

• Evolution
• Gajim
• Gwibber
• Pidgin

What is the difference between the “Indicator Display” plasmoid and the “Incoming Message” plasmoid from kdeplasma-addons?

Both plasmoids have the same goal, but the “Incoming Message” plasmoid tries to implement this goal with application-specific code: it has specific code for Evolution, KMail, Pidgin, Kopete and XChat.
The “Indicator Display” plasmoid on the other hand relies on applications to use libindicate and does not contain any application-specific code.

CMake and “make dist”, the simpler version

I wrote about using CPack to create a make dist target earlier today, but it turns out there is a much simpler way to do this, thanks to Christophe Fergeau for pointing me to it.

Note that this won’t work if your project is not using a version control system (but if you are not, then you are asking for trouble!).

Here are the necessary lines to add to your CMakeLists.txt file if your project is using Git:

set(PROJECT_VERSION "0.2.3")
set(ARCHIVE_NAME ${CMAKE_PROJECT_NAME}-${PROJECT_VERSION})
add_custom_target(dist
    COMMAND git archive --prefix=${ARCHIVE_NAME}/ HEAD
        | bzip2 > ${CMAKE_BINARY_DIR}/${ARCHIVE_NAME}.tar.bz2
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})

If your project uses Bazaar, replace the “add_custom_target” line with:

add_custom_target(dist
    COMMAND bzr export --root=${ARCHIVE_NAME}
        ${CMAKE_BINARY_DIR}/${ARCHIVE_NAME}.tar.bz2
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})

If you know how to do this with another version control system, please add a comment!

CMake and “make dist”

Update: Here is a simpler way to create a “make dist” target.

Creating a source archive

The other day at work I needed to create a release for some packages I have been working on (more on that later). Since I am using CMake for these projects, I looked around at how it could help me generate my source archives. CMake has a tool called CPack, which can generate cross-platform binary packages (.msi for Windows, .dmg for Mac OS, .rpm, .deb or binary tarballs for Unix) as well as source archives.

I found little documentation on how to tweak the way CPack generate source archives, so I am going to describe how I solved my problem. Maybe it can help others, or you can point me to smarter ways.

Here is a short extract of what I ended up with:

set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "2")
set(CPACK_PACKAGE_VERSION_PATCH "3")
set(CPACK_SOURCE_GENERATOR "TBZ2")
set(CPACK_SOURCE_PACKAGE_FILE_NAME
  "${CMAKE_PROJECT_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
set(CPACK_SOURCE_IGNORE_FILES
  "/build/;/.bzr/;~$;${CPACK_SOURCE_IGNORE_FILES}")
include(CPack)

Once you add this to your project, running make package_source will create an archive named “foo-0.2.3.tar.bz2″ (assuming your CMakeLists.txt file contains a project(foo) line).

Let’s detail these lines:

set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "2")
set(CPACK_PACKAGE_VERSION_PATCH "3")

Nothing fancy here, we just define the version number of our package.

set(CPACK_SOURCE_GENERATOR "TBZ2")

By default CPack generates .tar.Z, .tar.gz and .tar.bz2 archives. Set this variable to only generate .tar.bz2 archives.

set(CPACK_SOURCE_PACKAGE_FILE_NAME
  "${CMAKE_PROJECT_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")

By default CPack creates an archive named “foo-0.2.3-Source.tar.bz2″. The only way I found to get rid of the “-Source” suffix was to redefine the CPACK_SOURCE_PACKAGE_FILE_NAME variable.

set(CPACK_SOURCE_IGNORE_FILES
  "/build/;/.bzr/;~$;${CPACK_SOURCE_IGNORE_FILES}")

If you create your build dir inside the source dir, CPack will do stupid things such as including the content of the build dir in the archive. Fortunately you can tell it to ignore files with CPACK_SOURCE_IGNORE_FILES. I added my build and .bzr dirs (my work projects are managed with Bazaar).

include(CPack)

This is where the magic happen. Including “CPack” creates the package and package_source targets. It is important to add this line after the various “set(CPACK…” lines, otherwise they will be ignored.

Creating a “dist” target

This setup is nice, but it has two problems:

1. Running make package_source do not update CMake cache, which is painful when you are adjusting the various CPACK_ vars
2. make dist is more natural than make package_source

To fix both of those, I created a dist target like this:

add_custom_target(dist COMMAND ${CMAKE_MAKE_PROGRAM} package_source)

This line creates a dist target, and ensures the CMake cache is updated if you run make dist after changing the CMakeLists.txt (not sure why… Can somebody explain?)

Be careful…

CPack puts everything from the source tree inside the archive, including any file lying around. This is probably not what you want… To ensure you create clean archives, always run make dist from a clean source tree. A nice way to do this with git or bzr is to create a local clone of your working tree. The procedure is thus the following:

{bzr,git} clone <path/to/source/tree> tmp
cd tmp
mkdir build
cd build
cmake ..
make dist

You just have to make sure the “build”, “.bzr” or “.git” dirs are ignored in CPACK_SOURCE_IGNORE_FILES.

Hope this helps! Maybe I’ll come back later with a recipe for make distcheck, if I find the time to setup such a target.