Month: October 2007

Leveraging Qt For Smooth Transition Effects

Posted on by

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.

Qtopia Phone Edition on OpenMoko

Posted on by

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