Qt

To sum it up: it was an awesome party. We had a decently filled location, which surprised me because this particular party was announced less than one week in advance.

Starting at about 19:00 o'clock local time we saw a great show: Aaron giving an awesome keynote, Benjamin presenting KDE 4.0 apps on the Mac and Holger showing off KDE 4.0 on Windows in the typical understatement way of people from northern Germany . Thanks to Google for recording, Franz for organizing the streaming, and Dirk for getting a server capable of actually delivering the stream.



To me that keynote (which we will hopefully soon be seeing on Youtube), was en par with the ones the Steve's of this IT world deliver, just a lot warmer and more honest. Yet Aaron managed to present the incredible achievement that is KDE 4.0 in an amazing way.

After the keynote finished, the attendees had time to test KDE 4.0 and discuss various issues. As a special plus for those attending our party, we offered a special "KDE 4.0 Blue Lagoon Cocktail", which was very well received. (recipe on the right, sorry for the crappy pic). Thanks go to Peter for organizing beer, Natascha for doing an excellent job as a bar tender, the Netzladen for hosting and to AurISP and PBR Systems for providing a projector for everyone to follow the keynote.

Oh, and Qt is (also) GPLv3 now. Yay!

So it's been done: KDE 4.0.0 has just been released. This is not only the end of a long development effort, involving a lot of new ideas and even more sweat and tears in getting a .0 release out. It also marks the beginning of a new age in free desktop computing, new ideas and new technologies, some of which are still emerging and will find their way in later KDE 4 releases.

I was especially impressed with the page of the KDE Games folks, which makes you want KDE 4.0.0 just for the sake of playing some of the games they wrote and polished. A special hats off goes to the new KBattleship maintainer. The new version rocks. In related news, make sure to check the page of the KDE Education project.

So what does the future hold for KDE 4? Obviously, there will be lots of plasma applets and a lot of ported and new applications. Developing for KDE already is and will continously become a lot easier, especially due to the advanced scripting capabilities. To keep the learning curve low, we will do a developer tutorial sprint on TechBase once the dust of the release announcement has settled. And the best thing is: You can make a difference. No matter if you like coding, translations, doing arts or do something we don't have a position for yet: Get involved and become a part of something amazing.

PS: If you want to celebrate the new release in parallel to the Mountain View event next friday and live in the Cologne/Bonn area, drop me a mail.

Due to some rather strange pains in my back (probably muscle-related, I hope the doc will find out tomorrow), I am somewhat chained to my bed. With my action radius being limited significantly, I am doing what seems popular: I decided to give an update about my personal situation. To sum up 2007, it was a fairly nice but also stressful year, with a lot of changes in my private life, both positive and rather sad (which don't belong here, drop me a mail if you care).

It also saw the release of the english, slightly updated version of my book on Qt 4 and held an awesome study-related internship at the coolest toolkit-vendor ever. I hope this explains why I remained so silent on the blog and (even worse) on the KDE commit list. I kept active in the background however, keeping TechBase running along with Dominik and setting up other MediaWiki-based websites for KDE.

As for 2008, there is a lot of things I want to do. I won't bother you with all of them, just the very basic ones:

• Finish studies (finally )


• Get more involved in KDE development again


• Enjoy real-life even more than last year*

So, to all my friends, readers and KDE-enthusiasts i wish

A happy new 2008!

*(well actually, that looks like bad resolution at first sight, since 1 and 2 conflict with 3, but after all it's all about the right balance, right?)

I hate the days close to exams. I am pretty annoyed with learning by then, and the times I decide to call "creative breaks" get longer and longer. Yesterday, I was looking for something that might be fun, touching an area I haven't been touching before. Now I don't consider myself a graphics expert. As such, I am a total n00b when it comes to nice-looking effects.

However what has always bothered me is that despite virtually anyone having a bare minimum of OpenGL support nowadays, we still don't have OpenGL-accelerated blending or transitioning effects in KDE. Back when I was at Trolltech, Matthias voiced the same opinion. And so I decided to program something cool "when I would find some spare time". Now, as we all know, there is no such thing as spare time. It's merely a matter of feeling The Itch or, like in my case, feel like you need to do something funny for a change.

I think our users deserve some eye candy, so I hope a lot of people who write photo albums, etc, watch this. So I wrote a demo that leverages Qt's OpenGL widget, good old QTimer and the rather new QTimeLine class to transiate smoothly between two images. I'd love to see something like this in Gwenview or KPhotoAlbum for instance.
(I also feel that I owe a nice QtOpenGL example to the readers of my Qt 4 book, which I am linking here purely for commercial reasons, but that's a different story).

Anyway, highlights of the demo I came up with include:

• extra smooth transition using EaseInOutCurve


• toggling between fullscreen mode and window using Alt+Tab (although implemented quick and dirty)

As you dive into the source code, you will realize that there is nothing OpenGL specific about it. All it does is using plain Qt APIs. In fact, the source code allows for an easy replacement of QGLWidget with QWidget. After a recompile, the blending effect still works, although by far not as smooth on X11. This is because if you use QGLWidget, it will redirect all your Painter calls to a special paint device using a special paint engine, which translates your QPainter calls into OpenGL commands. You can, but don't have to bother with native OpenGL calls at all.

I wish it was possible to detect a software renderer in a generic way, but I'm afraid that will only be possible with GLX specific code. That way the code would simply not use a transition on non OpenGL-accelerated hardware. Hints welcome in the comments, please prove me wrong.

When the news about Qtopia on the OpenMoko made its round in the news, I was eager to find out how it would be, especially because the only platform I had seen it on was the Greenphone. Thankfully my friend Lars lent me his Neo 1973 to help me getting an impression. It still had one of the first OpenMoko Firmware images installed and couldn't even do GSM. So I took it home and flashed it with the binary release from Qtopia.net. I booted it up and... wow, it asked for my PIN, logged into the network and I had GSM working. So after two days of using it, here is a list of cool stuff:

• It's astonishingly usable without a stylus already (scrolling, dialing, etc), with exception of the querty keyboard (must-have #1)


• The adoption to keyboardless handling is very good, e.g. games that need one have been removed, applications got adjusted (must-have #2)


• Telephony just worked (not that obvious these days)


• The graphics look really polished


• and of course: the lock/unlock mechanism is really cool and a funny idea

So what did I notice? (Please bear in mind that this is the first public release of the OpenMoko-based firmware, so this is something that can be fixed)

• Suspend doesn't seem to work properly yet (issues with the OpenMoko kernel?)


• Without suspend, battery life is only about 6 hours


• Some redraw errors in the unlock application


• Speaker volume too silent, even when pushing everything to max

Now this is stuff that certainly can be fixed, and if there would be Marble available on Qtopia, too, that would even make for an awesome geo-location-based-services tool (Nokia seems to belive it's the future, and so do I). Awesome work, Brisbane trolls, and of course all the other devel trolls in Berlin, Munich and Oslo! I hope now that Qtopia is GPLed, Qtopia might become an interesting alternative to OpenMoko.

By the way: I was approached a few times by friends who asked me of the whole Qtopia on OpenMoko thing spoiled the OpenMoko development. Here is my view. The OpenMoko firmware is for those who like to have their X11 and all the crap running, Qtopia is for those who just want to have stuff working, without caring that its even Linux underneath. They don't need X11, the framebuffer is good enough and less complex to draw on (also, nobody keeps you from adding an X-Server to Qtopia or port Qtopia to Qt/X11. It's GPL, after all).