From time to time I need to take a screenshot of some application or a part of my desktop. The obvious solution in KDE is KSnapshot, which is perfect if you want a rectangularly-shaped picture.

Unfortunately, sometimes I want to capture something not rectangular, something which looks more like an ellipse, or even some odd shape. That means I have to take the snapshot, go to Krita, edit and save. Four steps. Ugh.

No more!

I have just committed free-region capture to KSnapshot, which makes possible to capture arbitrary shaps:

Now you can capture only the nice logo from our friends over at the Libre Software World Conference, no need to take a rectangle with a lot of background color:

And this would be the result:

Isn’t it nice?

Haiku is a free open source operating system compatible with BeOS. I’d say the BeOS community is the new Amiga community: they love their platform and will endure as many difficulties as necessary as long as they are able to run BeOS/Haiku.

A few months ago, Qt4 was ported to BeOS/Haiku. That’s great news because it means we Qt4 developers can now target a new platform (did I say CMake is also available for Haiku?). Arora quickly followed.

Now, KDE 4 is also available for Haiku. Freezing cool.

By the way, OS/2 is another of those everybody-thought-they-were-dead platforms which are being infused new software thanks to ports of Qt4 (they need money to complete the port, donate!) and CMake

Please note I am not a KDE-on-Haiku or KDE-on-OS/2 developer. I know zero of Haiku/BeOS and I forgot almost all I knew of OS/2 programming.

PS: Comments here do not work due to hosting manfunction

Today I received an e-mail from Vincent about some strange warnings dpkg-shlibdeps was showing when building from source the Wt packages on Debian:

dpkg-shlibdeps: warning: symbol pthread_join used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_delete used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_setspecific used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_detach used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_getspecific used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_create used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/ found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/ found in none of the libraries.

He asked if I knew what was that (a dpkg-shlibdeps bug?) and what did it mean, it case it was correct.

That error means pthread_join, pthread_mutexattr_destroy, etc are used by and but those libraries are not linked to by Wt’s buildsystem. I. e. the linker command line when putting and together does not have a “-lpthread“.

Is dpkg-shlibdeps right about that? Yes, it is:

  • uses in the XML library (Wt bundles the sources ot MiniXML and compiles them as part of
  • uses in WServer.C

So, if the buildsystem is not linking and to, why doesn’t linking fail with “unresolved reference” errors? It’s because of the link interface in Boost is wrong.

Link interface? What’s that?

If you are reading me via Planet KDE, you probably know what I’m talking about because Alex has written about this. If you don’t know what I’m talking about, keep reading.

Say you have, and

  • does not link to any external library, save for glibc
  • links only to and glibc
  • links only and glibc

When you run ldd, what will you get? This?

$ ldd => (0xb7f66000) => /usr/lib/ => /lib/tls/i686/cmov/
/lib/ (0xb7f67000)

or this?

$ ldd => (0xb7f66000) => /usr/lib/ => /usr/lib/ < ======= => /lib/tls/i686/cmov/
/lib/ (0xb7f67000)

The answer is you’ll see the second output: is linking to, although when you linked it you only did gcc -o libC.c -lB (no -lA, so no explicit linking to

libC -> libB -> libA

Why is that? Why is being dragged to It’s because of what we call “link interface”

As links to, by default,‘s ELF header will have every library links to as NEEDED:‘s dependencies have been transitively passed into! Usually that’s not what you want, therefore it is possible to specify a “reduced link interface”: given that is only used internally in (users of do not need to use any type or function defined in libA), there is no need to link to


  • As and link to from Boost
  • In Debian, Boost is compiled with threads (i. e. it links to
  • Boost does not publish a reduced link interface but the full link interface (i. e. every dependency of Boost is transitively passed into applications/libraries using Boost)

… even though and were not linking to explicitly, they were picking from and no linkage error happened. If would not export (it should not!), linkage of and would have failed and the authors of Wt would have noticed the bug in their build system.

While this is not a critical issue, it makes your application/library load slower, because it needs to resolve and load the NEEDED libraries.

Please note this discussion is valid for any operating system, including Windows and Mac OS X.

If you use CMake as your build system and you want to adopt a reduced link interface, take a look at the CMake docs for TARGET_LINK_LIBRARIES, particularly the LINK_INTERFACE_LIBRARIES section:

Library dependencies are transitive by default. When this target is linked into another target then the libraries linked to this target will appear on the link line for the other target too. See the LINK_INTERFACE_LIBRARIES target property to override the set of transitive link dependencies for a target.

target_link_libraries( LINK_INTERFACE_LIBRARIES
[[debug|optimized|general] ] …)

The LINK_INTERFACE_LIBRARIES mode appends the libraries to the LINK_INTERFACE_LIBRARIES and its per-configuration equivalent target properties instead of using them for linking. Libraries specified as “debug” are appended to the the LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties corresponding to configurations listed in the DEBUG_CONFIGURATIONS global property if it is set). Libraries specified as “optimized” are appended to the the LINK_INTERFACE_LIBRARIES property. Libraries specified as “general” (or without any keyword) are treated as if specified for both “debug” and “optimized”.

NB: The comments in this blog do not work due to a hosting issue

Are you a developer and use ACE, TAO, CIAO? Do you use and/or deploy to Debian, Ubuntu or any other Debian-based distribution?

If you answered affirmatively to those two questions, you have probably noticed Debian still ships ACE 5.6.3, which is 18 months old. The reason is twofold:

  • ACE is a complex beast. The source tarball generates 59 binary packages for 5.6.3, and that’s only to increase in the latest version (5.7.4).
  • The only Debian developer working on ACE, Thomas Girard, is too busy at the moment. He did a great job maintaing ACE for years but now it’s time for others to help him.

Therefore, if you use ACE and Debian directly or indirectly, please step in and help me get the latest ACE in Debian. I’m half done but I’m having trouble with autotools (the autotools build system in ACE seems to need some love, I’m probably moving to the traditional build system) and I do not know where to put some of the new libraries (DAnCE, etc).

NB: The comments in this blog do not work due to a hosting issue, please contact me directly by e-mail: or subscribe to the pkg-ace-devel mailing list.

You probably know I love Wt, the Qt-like C++ library for developing webapplications. I gave up on Ruby on Rails and PHP when I started using Wt about three years ago.

Koen and Wim, the authors of Wt, happen to be from Belgium and they attended aKademy 2008. I “arranged” a metting between Koen, Wim, Richard Dale (the KDEbindings man) and me. We talked about how great Wt is, how much the API ressembles Qt and how nice bindings to other languages would be. Guess what? A few months later, Richard had adapted SMOKE to Wt and had developed Wt::Ruby bindings. Impressive.

I attended last year’s FOSDEM and there we go again: over dinner we came with a new idea. Google Gears makes it possible to run webapplications like they were desktop applications. But it’s Python, it requires a Python interpreter an a load of libraries. Can’t we do the same thing with Wt and generate a single executable by statically linking everything? Can’t we? Of course we can! In theory, it would be very easy: start Wt with its own embedded server (wthttp) in a QThread, then load that in a QtWebKit-powered browser. Koen put that in writing as a “>GSoC idea but EmWeb (the company Koen and Wim founded to support Wt) was not accepted as a mentor in GSoC 2009.

It took me a long time to get started with WtDesktop because I was busy with other stuff but two weeks ago I finally started to cut the meat. And it turned out to be surprisingly easy! Yes, WtDesktop works! It’s not in Wt, it’s not finished yet, but I hope I will be able to work on it and have something very nice in a few weeks time (get WtDesktop Technology Preview 2 here; TP3 is in the works, clone this repository)

What will WtDesktop have in the future?

  • Port autodiscovery (for now it’s hardcoded to run on port 9000, I’m having some trouble mixing Qt and Boost signals and slots to make it choose a new port automatically). This is almost done in TP3, which will be available soon.
  • Call-outs: let the webapp go out of the web and add menus, toolbars, etc to the application when it’s linked against Yes, you read it correctly: if you link against you get a webapp with its own embedded webserver, if you link against you get a FastCGI module you can serve from Apache, IIS or whatever, and if you link against you get a desktop appliation. No changes to your code at all! I’d like to have some declarative language like QML for this but that’ll take some time.
  • Printing support. There is basic printing support (i. e. printing the whole page) already but I’d like to be able to connect buttons, frames, etc in the webapp to be able to print only some parts. This would require the above call-outs.
  • Session-sharing and session-stealing. Wt has all the DOM tree for each session in memory, therefore it is able to send the same HTML, CSS, DOM tree, etc to some other address. Session-sharing would be like Remote Assistance on Windows: you can see what the other client is doing but you cannot touch. Session-stealing would be like Remote Desktop: you can click, type, etc and the other client would see a “this application is being used by XXX (IP address: X.Y.Z.T)”.

So yes, attending conferences is definitely fruitful. By the way, I’m attending FOSDEM 2010. Let’s see if I come with some other great idea!

UPDATE: Added git repository

A long time ago I started hacking on a library I named libQtGit. As you’ll deduce from the name, it provides a Qt-like API to git, the stupid content tracker.

I had a vision for libQtGit: it was not an end in itself but a piece of a more ambitious framework/library tentatively named QVersioned or libQtVersioned.

QVersioned would provide QVersionedDir and QVersionedFile classes (amongst others, but those two are the most important). Those classes would essentially have the same API QDir and QFile have. QVersioned would open ZIP files and store a .git directory inside. There are cases, like ODF (which itself is a ZIP file) where nothing special is needed. For other cases (for instance, a .txt file), there would be a .txtv (meaning “.txt versioned”) which would be a ZIP file containing the .txt + .git directory (why ZIP? because it’s supported natively by Windows XP and newer and Mac OS).

Now, how did I intend to implement ODF versioning, which was going to be the “this thing works” case?:

  • The .git folder would store the uncompressed contents of the ODF file, i. e. XML, images, etc. This is needed to avoid duplication, allow diffs, etc
  • There would be also a full copy of the latest version (XML, images, etc) in the ZIP file, just like any ODF-capable application not supporting QVersioned would expect (these applications would just ignore the .git directory)
  • When a QVersioned-capable application opens an ODF file, it compares the XML, images, etc to the latest version in git:
    • If the diff is empty, last save was by a QVersioned-capable application, no action needed at moment
    • If the diff is not empty, last save was by a QVersioned-incapable application. A new “git commit -a” is performed. Yes, we probably have lost “versions” of the document in between this commit and the former one but something’s better than nothing.

By using libQtGit and QVersioned, it would also be possible to add collaboration features such as “send me an update” (i. e. send me a diff which transforms my outdated document into your latest version), collaborative editing (send diffs back and forth) and more things I cannot think of right now.

In case you are interested in the libQtGit API (remember QVersioned will offer a higher-level API), this is the signature of the method you would call:

Git::Repository::Commit* Git::Repository::commit ( const
QString& message = QString(),
const Commit* c = 0,
const QString& author = QString(),
const CommitFlags cf = DefaultCommitFlags,
const CleanUpMode cum = DefaultCleanUpBehavior );

That’s equivalent to “git commit -C commit_id -m “message” “.

CommitFlags is a QFlag and CleanUpMode a QEnum:

enum CommitFlag {
DefaultCommitFlags = 0x0 /*< git commit */, OverrideIndexCommit = 0x1 /*< git commit -a */, SignOffCommit = 0x2 /*< git commit -s */, AmendCommit = 0x4 /*< git commit --amend */, AllowEmptyCommit = 0x8 /*< git commit --allow-empty */, NoVerifyCommit = 0x16 /*< git commit -n */ }; Q_DECLARE_FLAGS ( CommitFlags, CommitFlag ) enum CleanUpMode { DefaultCleanUpBehavior = 0x0 /*< git commit */, VerbatimClean = 0x1 /*< git commit --cleanup=verbatim */, WhiteSpaceClean = 0x2 /*< git commit --cleanup=whitespace*/, StripClean = 0x4 /*< git commit --cleanup=strip */, DefaultClean = 0x8 /*< git commit --cleanup=default */ }; Q_ENUMS ( CleanUpMode )

For the "git commit -a -m "Save latest unversioned version on ODF document opening" ", we would use:

// Assuming 'repo' is a valid Git::Repository object

repo->commit ( "Save latest unversioned version on ODF document opening",
"(The application would probably take the
author's name from the product registration)",
Git::Repository::OverrideIndexCommit );

So, how is libQtGit doing? Well, the API is there for git add, commit, init, mv, rm, checkout, clone, branch, revert, reset, clean, gc, status, merge, push, fetch, pull, rebase, config, update-server-info and (partially) symbolic-ref.

When I say “the API is there” I mean “all the QFlags, QEnums, methods, classes and its translation to git parameters is done”. It’s just a matter of implementing the QProcess part, parsing output, etc. Boring and
time-consuming but easy.

Given that I’m busy with other stuff, and some people have been asking for the code for a long time (sorry Riccardo!), I have just published what I have now. It’s unfinished, barely tested and yet to implement in many places. But it’s a starting point. It’s available now from Gitorious:

As for QVersioned, nothing is done yet.

Yesterday I learned Drobe, THE site for Risc OS and Acorn news was closing as its news service, thus remaining in archive-only mode. I have never used Risc OS or an Acorn and there is none in my classic computers collection but it is still sad news.

But I digress.

I cannot remember how but somehow, via Drobe, I discovered Risc OS had an Internet browser called NetSurf and it was available for Linux now. I backported the latest version (2.1) for Hardy and Jaunty.

Rendering-wise, it’s not too good. Plugins did not work for me and I’d say JavaScript is not working either. But there are some interesting points: NetSurf has its own rendering engine, split in several libraries:

Everything is MIT licensed.

Summary: NetSurf 2.1, libnsgif, libnsbmp, libparserutils and libhubbub are now available for Hardy and Jaunty from my PPA

I’m going to use git for a project of mine and instead of parsing git’s output (which is the adviced way to use it from your application), I thought I’d rather use libgit and link to it. The first step was getting rid of autohell and moving to CMake.

This patch against git’s current master branch includes the CMakeLists.txt file and a few modifications to the source (mostly due to the different way variable replacement works in autotools vs CMake).

So far, only libgit, libxdiff and git are built. Will I go go for the other binaries (gitweb, gitk, etc)? I’m not sure, as I’m not interested but it shouldn’t be difficult to CMake-ize those.

I think the move from autotools to CMake could be very useful for the msysgit* developers, as they no longer would depend on MSys*

* I have not tried to build git on Windows with my CMakeLists.txt yet, I’ll do it tomorrow

** It’s not actually true yet: I run two bourne shell-scripts but I could easily rewrite those in CMake, too.

Update I’ve produced a new patch, as the old one did not perform a few needed renames

I am adding Strigi support to an application using the Strigi socket interface (it’s faster than DBus and, in my case, easier to use). When using the socket interface, Strigi needs to to know where the socket should be created (for instance, /home/pgquiles/.strigi/socket) and it will search for indices in a subdirectory of that directory (/home/pgquiles/.strigi/clucene if using the CLucene backend, /home/pgquiles/.strigi/estraier if using the HyperEstraier backend, etc).

So I was telling Strigi the socket should be created in /home/pgquiles/.strigi/socket and to use the CLucene backend, thus indices would be looked for in /home/pgquiles/.strigi/clucene. Problem is, I was not getting any result back!

    std::string socketpath("/.strigi/socket");

    const char *homeVariableName = "HOME";
    char *home = getenv(homeVariableName);

    if( 0 != home ) {
      std::string socketpath = std::string(home) + "/.strigi/socket";      

    socket.setSocketPath( (const char*)socketpath.c_str() );

Notice the subtle error with block-scoped std::string socketpath hiding method-scoped std::string socketpath. Due to that, Strigi tried to use a socket from /.strigi/socket (which did not exist) instead of the right one, so it did not even try to look for indices!.