Nokia + Microsoft WTF

by ⋅ 16 Comments

We just learned about the Nokia and Microsoft strategic partnership today and many people are concerned. I think the agreement is worrying for Qt, but even more worrying for Nokia. I foresee an exodus of current developers and Nokia mobile device users. Many Windows developers will come. Hopefully?

I really wonder who is actually benefited by this strategic partnership.

Nokia already had many mobile devices with Symbian, one with Maemo (and there could have been many more with Maemo, but for some unknown reason there weren’t) and Meego could have been adopted already (but again, for some reason, Nokia had not).

On the other hand, Microsoft had an operating system but no users. Virtually nobody wanted Windows 7. It was either Android or your own solution (MeeGo, WebOS, Bada, etc).

In my opinion, the next move we will see is Microsoft buying Nokia to be able to compete one-to-one with Apple and Google. I think it will not take too longer, probably they are just waiting for Nokia stock to fall a bit more.

So what should have been the change of direction Nokia should have done a few years ago?

In my opinion, when Nokia acquired TrollTech, they should have released at least 10 devices with Qtopia. Immediately. And dump Maemo.

In parallel, they could have added more and more Maemo features to Qtopia. By doing that, they would have had a good mobile operating system and applications in no time. There was even an X11 compatibility layer for Qtopia back then.

I did not understand why Nokia adopted Qt and went on with Maemo and Meego based on Gtk+, and tried to keep as much backwards compatibility (regarding to source compatibility, development methodology,e tc) with devices which barely had users (N770, N800 and N810). I think noone understood that move. From my point of view, that was a waste of time, money and effort, which ultimately led to Nokia’s demise.

PS: Yes, I still am a KDE on Windows developer and part of the Debian Qt-KDE team

Bootstrap your CMake project

by ⋅ 5 Comments

When I talk to people about the CMake build system, they like the fact that it generates native project files for the tools you already use (which makes possible to use distributed compiling, debugging, etc). Next to that, Visual Studio and autotools users complain about bootstrapping not being possible.

If you are using Visual C++, solutions probably work fine for you and it is a fact they work out of the box with VC++. However, do not even try to move to another platform (Linux, Mac…) or another compiler on Windows because it will not work.

If you use autotools, you generate the configure script on your development machine and your users just run it to prepare makefiles. Only a Bourne-compatible shell is required when trying to build. Moving to Windows, particularly Visual C++ will be quite hard.

CMake is in my opinion one of the best build-systems out there but there is one problem: you need to have CMake in order to build a CMake-based project.

Now add third-party dependencies, which probably use a different build-system, to the mix and suddenly building your software has become time-consuming and complex. In terms of money, that translates to lost revenue because there is a high probability people evaluating your software will give up before they even have something to test.

Nokia solves this by distributing Qt binaries for the most popular compilers (MSVC2005, MSVC2008, MinGW). But there is always someone using a different compiler: MSVC2010, a different flavor of MinGW, Embarcadero C++ Builder…

KDE on Windows solves this by having its own “meta-buildsystem” called emerge, which is written in Python, which adds a dependency on Python when you want to build.

Can’t we do better? Can we get all the advantages of CMake yet not depend on CMake being available?

Yes, we can. I tried to do that for Wt and implemented it in the form of winstng. It’s a small batch file for Windows and a Bash shell script (for Unix; I didn’t manage to remove one bashism) which automagically download, build (if needed) and install CMake, all the third-party dependencies, build them, and then download Wt and install it. Everything ends up in a self-contained location which you can move around*. And you do not need administrator permissions. Tested on Windows, Linux and Mac.

*For now that’s only true on Windows, on Unix platforms I have not removed the rpath for some libraries which use build systems other than CMake (namely, OpenSSL).

BTW, if you are at FOSDEM, there is a Wt talk on Sunday, 14.30-15.15: The next desktop is the browser.

FOSDEM 2011

by ⋅ 2 Comments

Another year, another FOSDEM. Yay, I’m attending again! The biggest open source event in Europe, with more than 200 conferences and 5,000 people.

This year I will be talking about KDE on Windows. Sunday, 10.15, CrossDesktop Room (H.1309). If you are interested in helping us with KDE on Windows development, in making use of KDE on Windows for your application, or just want to use your favorite KDE applications on Windows, then you should come.

First interview in BehindKDE

by ⋅ 1 Comment

I have started a new series in BehindKDE, the Platforms series. In this series, I will talk with developers of all the platforms KDE is available for: Windows, Mac, BSD, Solaris, Haiku (!), etc. Linux will be included in the form of KDE packagers for several distributions.

The first interview has just been published, it’s a long conversation with Patrick Spendrin (SaroEngels) about KDE on Windows, the technology they (we 🙂 ) are using, its current state and the challenges KDE faces on Windows.

I’m starting contacts with other developers for the next 2-3 interviews. If you want to make a proposal (a developer you’d like to have interviewed, questions you’d ask, etc), please add a comment to this blog post, or contact me by e-mail or IRC.

By popular request: Kopete KIPI plugin

by ⋅ 7 Comments

Should we call it Kipiopete? 😀

Every time I blog about KSnapshot or KIPI, people comment or even e-mail me asking for the same feature: make it possible to send pictures directly to a contact in Kopete.

I thought I’d need to fiddle with Kopete internals, or even wait until KDE Telepathy would be ready, but no: it turned to be very very easy thanks to the rich DBUS interface Kopete implements. Once more, the best way to implement this turned out to be a KIPI plugin, which means you can now also send to your contacts your photos from Digikam, your pictures from Gwenview, etc. Yay!

Mandatory screenshots:

Wait a second! What was that last screenshot? It looks like KSnapshot works on Windows!? Sort of, more on that soon.

A few warnings, though:

  • Facebook does not allow file transfers but Kopete < = 4.5.4 wrongly reports Facebook contacts as being able of accepting files. If you try to send a picture to a Facebook contact, the transfer will fail. This is fixed in Kopete 4.6 (i. e. the KIPI Kopete plugin no longer shows Facebook contacts).
  • For some reason, Pidgin does not accept several files at once. It seems Kopete tries to send them too fast, or something like that. KMess, on the other hand, has no problem accepting all my photo collection at once via MSN Messenger.

Libraries and link interfaces

by ⋅ Leave a Comment

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/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_delete used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_setspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_detach used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_getspecific used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_key_create used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/witty/usr/lib/libwthttp.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_settype used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_init used by debian/witty/usr/lib/libwt.so.2.2.4 found in none of the libraries.
dpkg-shlibdeps: warning: symbol pthread_mutexattr_destroy used by debian/witty/usr/lib/libwt.so.2.2.4 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 libwt.so and libwthttp.so but those libraries are not linked to libpthread.so by Wt’s buildsystem. I. e. the linker command line when putting libwt.so and libwthttp.so together does not have a “-lpthread“.

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

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

So, if the buildsystem is not linking libwt.so and libwthttp.so to libpthread.so, 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 libA.so, libB.so and libC.so.

  • libA.so does not link to any external library, save for glibc
  • libB.so links only to libA.so and glibc
  • libC.so links only libB.so and glibc

When you run ldd libC.so, what will you get? This?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

or this?

$ ldd libC.so

linux-gate.so.1 => (0xb7f66000)
libB.so => /usr/lib/libB.so
libA.so => /usr/lib/libA.so < ======= libc.so.6 => /lib/tls/i686/cmov/libc.so.6
/lib/ld-linux.so.2 (0xb7f67000)

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

libC -> libB -> libA

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

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

Therefore:

  • As libwt.so and libwthttp.so link to libboost_thread-mt.so from Boost
  • In Debian, Boost is compiled with threads (i. e. it links to libpthread.so)
  • 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 libwt.so and libwthttp.so were not linking to libpthread.so explicitly, they were picking libpthread.so from libboost_thread-mt.so and no linkage error happened. If libboost_thread-mt.so would not export libpthread.so (it should not!), linkage of libwt.so and libwthttp.so 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

CMake-ifying git

by ⋅ 10 Comments

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

Raising awareness of KDE on Windows

by ⋅ 6 Comments

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!

Record a screencast with ffmpeg

by ⋅ 3 Comments

ffmpeg has been able to record a screencast on X11 for a long time now, using the x11grab input format and the :0.0 device (for the first instance of X). You’d run
ffmpeg -f x11grab -y -r 12 -s 800x600 -i :0.0+480,200 -vcodec ffv1 -sameq ./out.avi
and get a lossless video of the upper right 800×600 area of a 1280×800 desktop. Easy. You could even transcode to a lossy format (such as H.264, Xvid or Theora) if you had a powerful machine.

On Windows it was not that easy. First of all, Windows is not X11, so x11grab does not work on Windows. You need to use GDI or DirectX but ffmpeg did not have support for GDI or DirectX capture. If you wanted screen-grabbing features in you application, either you developed your own solution (ugly, specially because of the video encoding part) or you used Camtasia Studio (Wink does not include a DLL or ActiveX component you can use in your app).

Ramiro Polla and Christophe Gisquet had a heated discussion about one and a half years ago and some very interesting code was shown. Unfortunately, neither Ramiro’s nor Christophe’s code would work with current ffmpeg.

Today I’ve finally brought Ramiro’s code up to date and it works with ffmpeg trunk. It is not perfect, though: it does not capture the mouse pointer, contextual menus shown as a result of a right-click and video scaling and color is not perfect (ffplay shows the video a little blue-ish). Patch. I’ll try and bring Christophe’s code up to date tomorrow, or fix Ramiro’s code.

PS: A request for ffmpeg developers: please, replace your custom configure script with some cross-platform build system. I like CMake but Scons, Waf and others would also do.