Most of my coworkers use Qt4 but only on Windows. Some of them did not even know KDE existed, much less that since KDE 4.1 there are official packages and an official installer for Windows.

Last week, I wandered around the office, occasionally assaulting people to show them KDE on Windows, the API docs, this-and-that widget, answering their questions (mostly technical), etc (if you know how tackatpromotioned Marble at past aKademy-s, you know what I did 🙂 )

So, what was the reaction of people to KDE? Surprisingly, extremely good! I was expecting more resistance to the fact that to use K* classes, KParts, etc you have to convert your QApplication to a KApplication but they went like “the advantages of using KDE classes and KDE’s ActiveX [that’s how some of them call KParts] are so obvious I will do that as soon as I installing a development version of KDE on Windows is easy”. People specially liked the Kate, oKular and KPlato KParts (although I showed KPlato 1.6 and only on Linux). The pie-like ToolBox menu in Amarok also received some praising.

My conclusion: I really think we should raise more awareness of KDE among Windows developers and the “wander-around-and-assault-for-no-reason” approach works very well. Try it with your Win32 coworkers and friends and blog about KDE on Windows. Let’s get some momentum for KDE4 on Windows!

If you use Ubuntu and have added my Personal Package Archive to your /etc/apt/sources.list, you surely have noticed I have “backported” a lot of “sensitive” packages Hardy: Qt4, Glib, Gtk+, Cairo, lsb-base, HAL, hdparm, alsa, GNU parted, PCRE, etc. There are a lot more packages, not that “sensitive”: Samba, CMake, Telepathy, GStreamer, Rails, Boost 1.36.0, libvirt, Qemu, KVM, rdesktop, git, Apache, rsync, etc

If Ubuntu Intrepid or Debian Unstable or Experimental had the latest upstream version, I backported it to Hardy. If upstream was newer, I took the latest Debian/Ubuntu packaging and used that for the latest upstream version, with some fixes here and there.

This usually works fine because I’m careful and I test the packages myself. Actually, that’s the only reason I backport stuff: I usually need versions newer than the available ones in Ubuntu.

So far, the count had been “broke: 0 – fixed: a lot”, my biggest “success” being providing a fixed GNU Parted for bug 107326 months before Ubuntu did.

This time, however, I have inadvertedly inherited a bug present in some update (probably HAL), which makes your keys work in a “funny” way. First user to report that to me has been Michael Adams: “Having updated with your backports, I notice that my arrow keys have been converted to macro keys: my side keys don’t work, and up takes screenshots”. And indeed that happens! In my defense, I have to say I had not noticed before because I seldomly reboot my computer, so changes had not been applied to my system yet.

What’s the fix? Apparently nobody knows for sure (sometimes a reboot fixed it, sometimes setkbmap is needed) but it’s been already reported, see bug 255008.

Why am I posting this to Planet KDE? Because although the bug report barely mentions it, it does happen with KDE, too.

PS: If you use the ATI proprietary drivers, dual-head configuration, and one of your monitors is rotated (i. e. in vertical instead of horizontal), please contact me. Rotation was easy with NVidia but I’ve been unable to get it to work with ATI 🙁

When I search for a particular software application (Wt, CMake, etc), please show me, in the results page, the latest version and a link to the download page (or even to the file, if there is only one file to be downloaded) so that I do not need to enter the website, check if there is a newer version and, if there is, go to the download page. Here you have a mockup:

Mockup of Google showing the latest version of CMake in the results page

Mockup of Google showing the latest version of CMake in the results page

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!.

This is mostly a self-reminder

I attended aKademy 2008 and there are so many things to write about I don’t even know what to start with. I’ll probably write something in a few days, when I’m feeling less sick (thanks to a Flemish waiter who had the OpenBossa guys, Knut and I waiting for almost one hour for dinner, I got a cold).

As you may know, part of my job (and hobby, too) consists on “shaking” software to make it compile on different platforms and with different compilers: I port Linux software which builds with gcc to Windows with Visual C++, or Visual C++ to MingW, or… well, whatever. It’s funny.

Back on topic: Wednesday as the Sun tutorials day and I got immediately interested in Sun Studio. Message to Sun Microsystems people: your installer is so broken on Linux it is impossible to make it work on Debian and Ubuntu (and I guess on anything other than RHEL). The only way I found to “install” SS12 was to download the Express version, remove the sh-code and untar the resulting package. It works but it’s so nasty hardly anybody would try that.

Sun Studio 12 is 100% ISO C++ compliant, which means support for wchar_t is not as good as most applications require nowadays. The best way to overcome this limitation is to use Apache Foundation’s STDCXX to replace SS12’s STL (which is STLport 4 (according to Adriaan, stdcxx would roughly correspond to STLport 6)

Building STDCXX is relatively easy, if you know the tricks:

  • export PATH=/path/to/sunstudioceres/bin/:$PATH
  • export CC=/path/to/sunstudioceres/bin/suncc
  • export CPP=/path/to/sunstudioceres/bin/suncc
  • export CXX=/path/to/sunstudioceres/bin/sunCC
  • You should be able to do this step by exporting CFLAGS, etc but it won’t work, so edit stdcxx-4.2.1/etc/config/sunpro.config and:
  • Replace
    CXXFLAGS= -library=%none
    CXXFLAGS = -library=no%Cstd -YI,/path/to/source/of/stdcxx/include/
  • Replace
    CPPFLAGS = -YI,/path/to/source/of/stdcxx/include/
  • Replace
    LDFLAGS= -library=%none
    LDFLAGS = -library=no%Cstd
  • make BUILDTYPE=12d
  • make locales(if you don’t use BUILDTYPE=12d, current Sun Studio Express Edition fails with yi_US, thus you need to edit stdcxx-4.2.1/etc/nls/gen_list and remove that line)
  • cd build && make install PREFIX=/where/you/want/to/install/stdcxx
  • At the moment, I’m trying to get Wt built with Sun Studio 12 on Linux. Given that SS12 is the compiler of choice for KDE4 on Solaris, I may try to get KDE4 built on Linux with SS12 at a later stage. That would help both the Solaris port and the Linux code.

    PS: Hello Planet KDE

    Yesterday I stayed up until 4:30 AM while trying to fix Amarok to works on Windows and when I got it to build it was so late I was too tired to test it. So I fired it this morning and this is the result (click for larger images):

    I have tested and it plays MP3, WMA, APE and whatever Magnatune streams on. Built with Visual C++ 2008.

    Update Two more screenshots added and in case you were wondering, yes, Plasma works!

    Yesterday I fixed the Phonon DirectShow 9 backend for Windows. Now audio and video are available to KDE applications on Windows, which means Amarok 2-trunk works! Currently, it can only play .WMA files (I think I have to install the .ax files for the MP3, MIDI, WAV, etc codecs in the KDE bin or libs directory, I’ll try and fix that next week). In the meanwhile, you need patch #6 if you want to build Amarok on Windows and hear something. Please note I’ve only tried to build it with MSVC2005, not MinGW, not MSVC2008 yet.

    That’s the title of a very useful article by Scott Collins which describes how to combine Boost and Qt in the same application. Unfortunately, Scott’s website went dark many months ago and I’d say it’s not coming back. Luckily, I was able to get a copy from Google’s cache before it was squashed forever. I’d say right now this is the only place in the web you can get this wonderful article: A deeper look at signals and slots

    Update: The Wayback Machine has a copy of the article. I’m keeping the PDF in my site just in case, anyway.

    IMHO is a weak organization and it’s specification are not taken seriously enough. Gnome and KDE are suggesting developers follow those specs, as opposed to strongly demanding they do. The end result of that is worse interoperativity between Gtk+/Gnome and KDE applications, therefore users get frustrated.

    IMHO KDE and Gtk+/Gnome should define an “acceptflow” to follow in order for an application/library to be included. Briefly: if you are not using fd.o’s specs, you need to really convince us there is a good reason for that.

    Expanding it, this is my proposed workflow:

    1. Developer John Doe writes an application/library
    2. Developer John Doe submits an application or library to KDE or Gnome/Gtk+
    3. Is the application good?
      • No => Not accepted, needs improvement
      • Yes. Next step
    4. Does the application or library follow specs?
    5. Yes => Accepted
    6. No. Why not?
      • There is no spec => Propose one, when there’s agreement in the fd.o community about the spec, go back to step 1 if you want your app/library in the official repository or keep it in your own repository (it will not be part of the official Gtk+/Gnome or KDE)
      • The spec is good but John Doe is smarter than anyone in the world and does not want to use a “bad” spec => Sorry but go back to 1 if you want it to be included in the official repository, or keep your own repository. Fix your ego, too.
      • The spec is not good enough, it’s to up to reality
        • Go to and propose improvement of the spec. When the spec is good enough => Go back to 1 if you want it to be included in the official repository or keep your own repository.
        • Go to Other people working on applications/libraries using that spec do not want to update the spec to be up to reality, for any or no reason => Go to next step
    7. So, there is a spec but it’s not good enough and there’s no way the other people using that fd.o spec will update it. Is John Doe’s application/library really good? I mean, is it true that what he wants to change in fd.o spec should changed?
      • No. Sorry John Doe, you are not the smartest guy in the world => Go back to step 1 if you want your app/library in the official repository or keep it in your own repository. It will not be part of the official Gtk+/Gnome or KDE.
      • Yes => Accept John Doe’s app/library in the official repository and keep trying to update fd.o’s spec.