The news broke in last week in the Qt community: Qt SDK, in whole, has been ported to Android.

Was it Nokia? No, it wasn’t

Maybe Google? Not either

It’s been a Romanian developer called Bogdan Vatra. In his spare time.

I interviewed Bogdan for Behind KDE last week and today the interview went live. Want to know more? Start reading!

Now we only need Android-phone owners to start porting KDE libraries, applications and all the eyecandy to Android. Sadly, I do not own an Android device 🙁

I have been packaging for Debian for a few years now. My first “serious” package was Wt back in 2007, but I had been backporting for Ubuntu for at least 2 years already, which means I have been doing .deb packaging for about 5 years (!).

Last week I decided it was about time stop nagging my sponsors (Vincent Bernat, Thomas Girard and Sune Vuorela) every time I wanted to update the packages I maintain (witty, ace and libmsn), and I finally started the Debian New Maintainer process.

The main reason I had not applied for Debian Maintainer yet was it requires some bureaucracy and, well, I’d rather spend my time coding or packaging than doing paperwork 🙂

I sent my Declaration of Intent and soon after, Thomas and Vincent replied and supported my application with very very nice and kind words. Thank you, guys! I’m flattered! 🙄

Had I known I would be buttered up so much, I would have certainly applied a long time ago! 😀

But you know what is the best part of this? It shows how open source projects take advantage of all the tools and communications channels we have (IRC, mailing lists, sprints, conferences, etc), and make distributed development work very well: here we have a 900-developers project in which two French guys are praising an Spanish guy they have never, ever met face-to-face (only e-mail, occasional IRC, and the most important of all: code review). Meritocracy at its full extent. Have you ever seen that in a traditional 100,000 workers company with hundreds of developers working in a single project?

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

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.

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.

Do not waste my hard disk!

I recently acquired an 2 TB hard disk drive, which I immediately formatted with ext4. Given that mkfs.ext4 defaults to 5% reserved blocks for too, that amounts to 100 GB of lost* space.

Wow. 100 GB. On a desktop machine. For root.

While mkfs belongs to e2fsprogs, I think this requires action on the distributions side. Let me explain.

If you are installing a server, 5% makes perfect sense: there are a lot of logfiles, updates, potential break-ins and other disasters-to-happen for which root-reserved space will be preciously required. 5% is a good choice here. If 5% is too much (or too little), it will not matter: any decent sysadmin knows mkfs.ext4 -m and tune2fs -m (if you don’t, Martin will teach you).

On the other hand, if you are installing Ubuntu on your laptop, you probably don’t know shit about mkfs, tune2fs, 5%, etc. You only know by removing Windows and installing Linux you’ve magically lost 100GB of space. Vanished.

So here is my request to Linux distributions: when installing a distribution in “desktop profile” (i. e. not Debian in “server” profile, RHEL, SLES, Ubuntu Server, etc), DO NOT RESERVE 5% to root. 100 or 200 MEGABYTES should be more than enough.

* Yes, I know it’s not really “lost” but just “unusable by normal users” but that technicality doesn’t matter to 99% of the people out there.

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.

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.

Ubuntu Jaunty reached end of support life last October and apparently packages have been removed from Launchpad PPAs too.

Given that it is impossible for me to build binary packages for Jaunty in the Wt PPA due to missing packages, the Wt PPA will no longer provide new packages for Ubuntu Jaunty. The last stable version of Wt for Jaunty is 3.1.6.

On April 2011, Karmic reaches end of support, and Hardy reaches end of support for desktop (support for servers will be available until April 2013). I will provide Wt packages for those distributions while Launchpad supports them.

Packages for 3.1.7a are already available for Ubuntu Maverick, Lucid and Karmic, as usual. Packages for Debian Lenny (in the Wt OBS repository) and Ubuntu Hardy packages will be ready in a few hours. Source packages for Debian Sid are available from mentors.

The screenshots.debian.net site is a public repository of screenshots taken from applications contained in the Debian GNU/Linux distribution and its derivates like Ubuntu.

It was created by Cristoph Haas to help people get an impression of what a certain software will look like on your desktop before you install it. Everybody can take screenshots and upload them through the upload form. So far there are about 3100 screenshots, which is actually a small number if you consider Debian Squeeze contains about 15000 source packages

After I hacked a bit on KSnapshot, the KDE snapshot tool, Sune asked me to add an export to screnshots.debian.net command. I had not thought of it before but that looked like a great idea, it would make the process or taking-screenshot, visit-upload-form, upload-each-screen so much easier!. So I started to develop my first KIPI plugin.

Here is the resulting Debian Screenshots plugin, as you would use it in KSnapshot:

Being a KIPI plugin, it is available not only from KSnapshot but also from Digikam, Gwenview and the other applications which support KIPI plugins:

Which makes me think: what about having a debshots (the software powering screenshots.debian.net) installation over at kde.org and have screenshots for all the KDE applications? What do you think? Promo team? Sysadmins? Setting it up shouldn’t be difficult: I’m no Python or Pylons expert (I’m more of a Ruby and Wt C++ guy 🙂 and got it running in a VM in an afternoon, even solving some SQLAlchemy 0.6 issues.