sorted by: recent | see :
popular
Content Tagged with Qt + KDE
Workflow and switching to Git, part 2: The tools
In the first part of this blog, I discussed a bit the change process and the development process we’re aiming for.
It’s interesting to realise that we’re going through the same process both in KDE and Qt. It’s also interesting that it’s happening at the same time for both — well, slightly ahead for Qt. That’s not, however, a coincidence.
I read a comment on the dot article about opposing a VCS switch every two years. Well, we’re not switching just for the fun of switching. We’re doing it because there are many compelling reasons to do so. (Also, it’s been over 3 years since the Subversion switch, about 4 since we started seriously considering it; Trolltech has been using Perforce for almost 9 years)
And it’s happening now because the DVCS tools have matured enough that we can migrate massive repositories into it. The Qt repository right now has about 170,000 commits and is over 900 MB in size (in Git, well packed). And the KDE repositories I imported had 79404, 71892, 60182 commits for kdelibs, kdebase and koffice, respectively.
And because the old processes and tools have become outdated. And, finally, because we’re people and we talk 
(that is, exchange of experience and opinions)
Switching to Git
So far I have not approached the second part of my blog title. There’s a very good reason for that: most of what we want to do, the workflow we want to introduce, does not depend on any specific tool. There are feature requirements that many tools do not fulfill, but many do fit the bill.
So why Git, in specific?
We had a lengthy process internally at Trolltech trying to decide whether we should switch to a DVCS and, if so, which tool it should be. That was a very interesting process, but one that would deserve an entire blog on the subject. We had a restricted set at the beginning, but only two serious contenders at the end: Git and Mercurial.
At one point, we came up with a list of what were the criteria we were going to use to make the decision. And then we took a look at which criteria were showstoppers. At the end of the process, there was a clear winner.
The most important criteria in that decision were:
- Quality of the conversion process (from Perforce)
- In-house knowledge of the tool
- Ability of the tool to support our proposed workflow
While the latter criterion was a tie between Mercurial and Git, the first two is where there was a clear winner.
(Disclaimer: there were other reasons, with a varying degree of importance, including some where Git lost to Mercurial)
And if you look at it, those are the exact same criteria that are of importance to KDE now. Sure, there are other tools that also do the job, but who’s going to do the conversion? Who’s going to support and help the developers who aren’t familiar with the tool?
For close to a year now, we’ve had the kde-scm-interest mailing list, whose mandate is to propose a plan to convert from Subversion to another VCS (or Source Control Management - SCM) and how the layout and workflow would be with this tool. Which VCS, it’s not specified. Any is welcome, barring CVS (we’re not going back), Subversion (it’s not conversion if we stay where we are) and solutions that aren’t Free and Open Source.
If you inspect the archives, you’ll see that there’s only one contender. So far, anyways. Others are more than welcome to join and repeat the process for other tools. But mind you: you’re a year behind schedule.
This weekend, I finished converting the KDE Subversion repository into Git. The process created no less than 493 different repositories: I decided that each application in extragear, kdereview, kdesupport or playground should get its own repository. There will be more when I run it again.
The process isn’t correct yet. There are definite import errors found: for instance, Thomas Zander inspected the the KOffice repository and realised that several branches were missing. What’s more, I still have a few ideas to do copy-with-history, which means preserving correctly the moves in SVN. Many of our projects originated in the old kdenonbeta, which I didn’t import.
I am forced to realise that Git isn’t completely ready for us yet. I’ve been using Git for well over a year now and I can see it improving build after build. 1.6.0 is very nice, but not there yet. So I ask the Git developer community: how do we handle 493 separate but related repositories? Mind you, we want to maintain the ability to build them all with very simple commands.
So, while Git is by no means decided for KDE — well advanced, I’d say — it is decided for Qt. We have kickstarted the process to completely switch to Git. Very soon now, we’ll be in the final leg of that process and will hopefully have some news on it. Our goal is to stop using Perforce for Qt 4.5 by October 1st.
Workflow and switching to Git, part 1: Processes
You know that with the Title I chose for this blog, I could be talking about Qt or about KDE. It’s ambiguous…
Yesterday, the dot had an article about a new development process for KDE that requires the use of a Decentralised Version Control System (DVCS for short). Believe me if you will, I had nothing to do with that article: I had not talked to Jos before he published it and I even admit to not attending the talks at Akademy on the subject.
But it was a pleasant surprise to read it.
Resistance to change
I’ve been discussing the switch to a different VCS for KDE and for Qt for over a year now. I’ve met a lot of resistance and the article on the dot was no different. There’s a lot of people who oppose the idea.
There’s always resistance to change. People don’t do it out of malice. Quite to the contrary, they do it because resistance to change is a natural reaction. It’s a way of your body and your mind letting you know you’re exiting your comfort zone. And that’s a natural human reaction. Brides and grooms having cold feet the morning of their wedding wouldn’t be a cliché otherwise: they’re about to make a life-changing decision.
Really, look back to all your life-changing decisions and events in your life (gradual changes don’t count). How many of those did you jump into with two feet ahead? Not many, you’ll agree. Marrying, getting a new job, moving to another city or country, for example, are all life-changing decisions. Incidentally, I’ve moved between countries 4 times already and only one of them (the last one) was with two feet ahead: it was when I decided to come back to Trolltech in Norway.
So the resistance we’re seeing now in the KDE community and inside the Trolltech (a.k.a. Qt Software in Nokia) developer community is natural. Some of the criticism is based on technical issues that have to be addressed, most is only fear that has to be managed.
In fact, there’s a whole profession on that, which is called Change Management.
New workflow
The article on the dot discussed the development process where “It’s always Summer in trunk”. I don’t know who coined that expression, but it’s a nice one. I think it appeared in the KDE circle in a blog by Sebastian Kügler: he asked the question “What if we never froze trunk?”
I was part of the discussions that led to that question, when we were discussing where Phonon would live. With my Qt hat on, I was asking for anywhere where “there’s no freeze when TT developers are working on development.”
In his blog and in the article, Sebas and others are advocating this idea. It’s something we already do for Qt’s development: the mainline of development never freezes. The feature freezes are preceded by a branching. In KDE terms, it would be equivalent of branches/KDE/4.1 branching off trunk/KDE just before the feature freeze.
That’s fine by itself, but you need the proper tools to pull it off. Remember that you’re going to work extensively with two branches. To give you an idea of the work involved, from the moment that Qt 4.4 branched off the mainline until today, there were 7744 commits into the Qt 4.4 branch (2771 of which after 4.4.0) and 9768 in the mainline (that includes the 4.4 ones). Whereas in KDELibs, there were 3783 commits to trunk since the 4.0 branch, but only 590 into the 4.0 branch since the same point. That’s approximately the same time period.
But the workflow goes beyond “It’s always Summer in trunk” (we’re already there with Qt and I said this blog is both about KDE and Qt). It’s about doing most of the development — which is where most of regressions occur, potentially — in separate branches. More than that, it’s about maintaining an ultra-stable branch somewhere.
If development is where “hot” is, then I’d say that actually “It’s always Spring in trunk”. We don’t want trunk to overheat — even economists say overheated economies are bad (cf. China). We want it to be a self-sustaining exothermic process. Like Spring, there should be periods where it cools down a bit more, there should be periods where it’s warmer than usual.
(I could also have chosen Autumn, but I thought Spring made my analogy look nicer)
Finally, we want developers to feel like experimenting without fear of breaking stuff. We want developers to freely collaborate with each other. And we want new developers to feel readily welcome, not second-class citizens. Granted, obtaining a KDE SVN account is rather easy, compared to many projects out there. But I’ve heard from many new Qt employees who felt like their first commits were very daunting. It was my case too.
Qt 4 on maemo
I love Qt, which is one reason I work for Trolltech^WQtsoftware in Nokia. and thanks to the efforts of the qt4 on maemo project Maemo Qt4, there is yet another platform/device open to any application that is created with Qt4.
Here is my old-yet-updated Gutenbrowser project on Maemo on n810. (the copyright on gutenbrowser is 1998-2008! now). I don’t work on it as much as it needs. Especially now with rug rats and yard apes about.
All it took was a recompile!
Just install the scratchbox sdk for maemo. Grab the qt4 for Maemo sources, compile, install them, and your good to go! hmmm… what’s next?
font anatomy
For the last 5 years a huge focus of my work has been on fonts and text. You know you went to far when you can tell the difference between a Helvetica and an Arial by just looking at the printed ‘a’.
Its unsurprising that people end up asking me what the difference is between leading and linespacing, why the customer claims we don’t do kerning for that specific font, why WYSIWYG actually fails for most people. I naturally can’t be because I’m the only one stupid enough to claim to know this, right?
I considered claiming ignorance, but then my weird behavior may no longer have any reason, so that would just make me a worse freak. Instead I just wrote an application that shows everyone how text works. And I’ll write a blog or two about what you can see on screen and how that relates to your questions even before you have them. Genius or what?
So, here is an example text;
let me quickly go over the different parts. In red we have the outline, this is the total amount of space that the text takes. This is what is reserved in your user interface for the text. The sizes you see on the right hand side are the major anatomical dividers of a font face. Much like your body has a head and legs (I’m making assumptions about that, work with me). The baseline is the only one that is really interesting to point out. it’s the zero-point for a font. All measurements start from there. So you have a part that’s above and a part that’s below the baseline. I’ll leave it to your imagination to mirror that to your own anatomy.
In blue we have the size taken by the individual characters. But when we are talking about fonts we actually should be talking about glyphs. There are subtle differences, but I won’t bore you with that. Each glyph has its own rectangle as you can see in the blue. This is useful to see since the m is wider than the j, which is useful to know since you position the characters next to each other. The blue little gradients are helpers (called bearings) to position the glyphs better so they visually look more pleasing.
Ok, with the basics behind you here are a bit more interesting things; consider the two following screenshots.
The only difference is that kerning is turned on for the first and turned off for the second. Notice how the blue boxes overlap in the first image and how they are simply placed side by side in the second.
In general you want kerning to be turned on, its on by default in Qt because it increases readability.
Last example; this one is tricky.
Fonts are designed in a way that they can be scaled and reused for any size. Which is a pretty neat idea since it avoids using a crystal ball to figure out which sizes to ship your font in. There is a little problem, though. A font that is printed on paper at 10cm per character needs a lot of detail but if you use the same character at on screen at just a couple of millimeters height, you have problems to make that one look good.
So, font makers ship something called ‘hints’. Which make their fonts look better at smaller sizes then the computer could do automatically. This is enabled per default and is practically speaking exactly what you want.
Except for one problem; if you add all those little adjustments they can add up. So much that if you have a sentence you can have a word that fits just fine when you show the font on screen, but if you then take the same width and same text but on paper, those little adjustments may just move a word to the next line.
In other words; hinting gets in the way of what you see is what you get text-layout. So, in Qt you can turn this off. Allowing you to get the exact same line-breakings on screen as you get on paper.
Look at the following two screenshots. You will see a little spacing between the little blue squares in the one where the hinting is turned off. We call this mode ‘designer metrics’.
if you want to play around with this stuff yourself, here you can find the sources;
svn checkout svn://labs.trolltech.com/svn/graphics/fontAnatomy
For the people that are still here, thanks for sharing the pain! And I’ll answer the question of “why should I care!”. The concepts shown in this blog have good support in Qt4. The point to take home is that the font is the one that specifies all the information. If the font doesn’t have kerning, game over. If the font has horrible sizing information, you are out of luck. With this little tool at least you can see the differences that different fonts make.
Fun with D-Bus at Akademy
To summarize my achievement at Akademy:
[Argument: a{sv} {"a" = [Variant(int): 1], "b" = [Variant(QByteArray): {99}], "c" = [Variant(QString): "b"], "d" = [Variant(uint): 42], "date" = [Variant: [Argument: (iii) 1977, 1, 1]], "datetime" = [Variant: [Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0],[Argument: (iiii) 8, 59, 31, 0], 0]], "dtlist" = [Variant: [Argument: a((iii)(iiii)i) {[Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0], [Argument: (iiii) -1, -1, -1, -1], 0], [Argument: ((iii)(iiii)i) [Argument: (iii) 1977, 9, 13], [Argument: (iiii) 0, 0, 0, 0], 0], [Argument: ((iii)(iiii)i) [Argument: (iii) 2006, 6, 18], [Argument: (iiii) 13, 14, 0, 0], 0]}]], "e" = [Variant(short): -47], "f" = [Variant: [Variant(int): 0]], "ismap" = [Variant: [Argument: a{is} {-47 = "c", 1 = "a", 2000 = "b"}]], "lldtmap" = [Variant: [Argument: a{x((iii)(iiii)i)} {0 = [Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0], [Argument: (iiii) -1, -1, -1, -1], 0], 1 = [Argument: ((iii)(iiii)i)[Argument: (iii) 1970, 1, 1], [Argument: (iiii) 0, 0, 1, 0], 1], 1150629776 = [Argument: ((iii)(iiii)i) [Argument: (iii) 2006, 6, 18], [Argument: (iiii) 11, 22, 56, 0], 1]}]], "pointf" = [Variant: [Argument: (dd) 0.5, -0.5]], "ssmap" = [Variant: [Argument: a{ss} {"a" = "a", "b" = "c", "c" = "b"}]], "time" = [Variant: [Argument: (iiii) 8, 58, 0, 0]]}]
Looks scary? It’s supposed to. D-Bus supports recursive complex types like structures, maps or variants, and until now, neither the Qt D-Bus viewer (part of Qt’s demos) nor the qdbus command line client were able to dump the contents of complex arguments. So, one day of hacking later, and thanks to a small API addition from Mr. QtDBus Thiago, we can now show pretty much everything that comes through the bus. The above example shows the output of one of our D-Bus tests - you can find complex structures inside variants and complex structs inside maps, and everything is nicely dumped.
But don’t worry - not many interfaces use deep nesting. Why we started to write the code in the first place is to display rectangles (4 integers in a D-Bus structure) from Qt’s D-Bus accessibility, Decibel’s properties (a D-Bus map structure) or some of the more complex calls of Telepathy.
The code will be available in Qt 4.5’s snapshots, happy introspecting!
P.S.: Many, many thanks to the organizers of this year’s Akademy. As always, it’s a great pleasure to be here.
In the flow
Sometimes when you think you’re on to something, and you end up in the flow, so bad, that it overshadows everything you’re doing. Ariya and I were working on optimizations in Graphics View and stumbled over an optimization for clipping that made a certain benchmark run 40 - forty - times faster. The patch has no known side effects, comes perfectly for free, and even opens up a couple of more optimizations we can do.
I couldn’t think of anything else on the way home from work. When I came home, I ate dinner, and immediately ran over to my home desktop, installed Git, and tried to find some way to continue where I left off.
It’s a wonderful feeling. If this patch really works this well, it’ll make it into Qt upstream, for everybody’s benefit. Mix that together with a lot of other optimization work that we’ve done, and hopefully things will truly fly.
I, for one, am looking forward to Qt 4.5 :-).
too much Qt going on!
A great deal of things are happening for Qt right now. Very exciting news:
Qt frontend for Mozilla engine (or, rather, has finally been dusted off and updated) Now we have two of the best browser backends to choose from. (or three if you want to use that ActiveX thing)
and
Nokia gives out free N810 devices to developers in Akademy 2008. Wow, thats a heap of n810’s to throw around.
Too bad Kate forgot to mention the other talks from Nokia:
- Harald - Programming for embedded Linux
- Andreas - How Graphics View Works
- Simon - QtWebKit! (We are part of Nokia now).
- Girish - OpenDocument support in KWord 2
- and playboy Zack’s talk on Gallium3D - Graphics Done Right
and not to forget about former Trolls
And if course, I cannot really yet mention all the really powerful great stuff being developed at Qt Sofware/Nokia.. but I really want too! Because its just too cool and will blow your minds.
Opendocument format
The Open Document Format (ODF) is an ISO standardized method of storing rich text and other office data. The ODF standard has grown in popularity over the last years quite a bit. Many governments around the world have passed laws stating that any sort of communication between the government and its people has to be done in ODF.
The attraction for ODF is strong, it is the first standard in this field that is completely open and it has a wide enough coverage that you can store your word processor and even most DTP documents in it without losing data.
I find the part where the standard is open very important, as an individual I have been able to sit on the ODF technical committee and I have been able to co-decide the direction of the standard. Various list-item related stuff has a finger of mine in there, for example.
Equally important is that everyone who wants to can implement ODF support in his or her application. All the information is available to do so, for free, on the web.
So, for end users the biggest advantage of the uptake of ODF is that more and more applications will standardize on this one format and thus applications will be much more interoperable. OpenOffice and KOffice are the early adopters here, I expect that many more applications will start to generate or consume ODF in some form or other. For example to export an abstract dataset to a nicely formatted document ready for printing, or the web.
Currently rich-text is mostly exchanged between different applications as html. Unfortunately html was not designed for this purpose. Sending an email with html markup kind of works. But you should take a look at the html that Qt or Word generate. Loads of extra non-html tags are written out just to put the layout information somewhere when html doesn’t have any equivalent features.
Those made up tags will be lost when the html is opened by another application than the one that created it.
Longer term I expect to see email applications to send ODF as well as html in their emails. Just so they can use the much broader ODF set of features.
Interestingly, a text exchange format gets more useful when more applications support it. This should be obvious
To speed up ODF recognition Qt 4.5 will ship with an ODF writer. Qt’s text module turns into a one stop document generation API where you can use QTextCursor to create your document via a nice API and you can then export the created QTextDocument to ODF ready to be opened by any opendocument implementation. Naturally exporting to plain text and html are still supported, as is printing to PDF.
Support for writing ODF in Qt sets a trend that we believe in the OpenDocument Format and we think its useful to have for our customers, the open source community and all end-users out there.
I always think its important to point out what our current solution does not do, just to avoid disappointment. The QTextDocumentWriter has support for each feature in Qt. So you can expect all features you can access using QTextCursor to be exported. This, however, is a subset of features in ODF. Qt’s ODF-writer does not aim to support each and every feature in ODF. So don’t expect you can write spreadsheets or some obscure ODF-text features that Qt doesn’t have.
There is work going on to make an ODF Reader too for a future release, the aim is to support all the features we write out but also try to map ODF features to Qt’s feature set where it makes sense.
The writer is in the unstable snapshots already, and will be released in 4.5. You can find the documentation online at; doc.trolltech.com/main-snapshot/qtextdocumentwriter.html
Zooming text
Some of my colleagues on the graphics team have been writing graphics dojo demos with impressive speed and with a rainy weekend I thought I’d get into the action.
As I’m regarded as the text guy I thought it would be fitting to have a demo that uses text, so I made a text effect class that animates text fading in and fading out.
One thing that I see a lot of people do is that if they want to zoom into text, they change the fontsize. There is a fundamental problem with that approach as text doesn’t scale linearly (due to hinting). So in Qt4 we have a much simpler and more powerful way of scaling text that fits better in graphics concepts. You simply scale the QPainter during painting.
This means that if you call myPainter.scale(2,2); your 12pt font will suddenly appear as a nicely scaled 24pt font. Or, more accurately, it will show the original text at 200% zoom.
This is very simple and due to us reusing the same font settings we avoid recalculation and text layout. So it will actually be quite fast. So fast that you can animate it quite smoothly. As is shown in the demo.
There is not much more to say about it, so just grab the code and run it!
svn checkout svn://labs.trolltech.com/svn/graphics/dojo/zoomingtext
New.s.
New business cards (not arrived yet). New employee badge (photo looks bad, as always). New email address (@nokia.com). New phone (starts with N). New intranet (huge). New Desktop (KDE 4.1 - I’m so impressed by you guys). New presentation templates (for my Akademy presentation). New marital status. New version control system (git).
And a new patch to make Qt 4.4 build within the LSB 3.2 environment, we’re getting very close to having one binary Qt/X11 Linux version to rule all distributions (bye bye distribution pain): lsb3.2-20080801.patch
Disclaimer: The patch above is unsupported, please contact my first name dot last name at domain starting with N for questions.
Releases and other stuff — three blogs for the price of one
Qt released
Since the saying “The release is not out until you blog about it” is still in effect, I have the pleasure of announcing that Qt 4.4.1 has been released.
Here’s the download button:
The 4.4.1 release is a patch-level release, meaning it’s a bug-fix release on top of Qt 4.4.0, maintaining both forward and backwards compatibility. It’s a drop-in replacement for Qt 4.4.0 and shouldn’t cause you any problems.
The full changelog can be found on our website.
This release happened about a month later than I had originally planned to. We postponed it until we could make sure that 4.4.1 is better than 4.4.0. Also, we can find explanations relating to Summer in Norway:
- Key people leaving for vacations
- Scheduled power supply cuts
- Air conditioning machines being turned off in our building
- Temperatures in Norway being quite high this year (often reaching 30°C)
And you thought that Winter in Norway was a problem…
KDE 4.1 released
Of course, I couldn’t let it pass that KDE 4.1 has been released, dedicated to KDE long-time contributor Uwe Thiem. Uwe had been doing a great job spreading Open Source and Free Software in Africa (Namibia to be precise). And many would say that’s where it’s needed the most.
In any case, KDE 4 has come a long way since the 4.0 release back in January. Back then, applications were great; the desktop was shiny and new, but limited. Many things I was used to simply didn’t work. Even for a long-time KDE contributor such as myself, it was hard to let the good, old KDE 3.5 go. But ever since KDE 2.2, I’ve always used the bleeding edge version. If using it back then wasn’t a problem, today is should be even less.
But that’s old history! Six months have passed!
KDE 4.1 is a lot better today. Many of the things that people complained about in Plasma have been fixed. And, of course, the applications that were already great got even better. Everyone deserves a praise for their work, however minor their contributions might have been. (I submitted only a few crash fixes)
Sure, it’s not perfect — nothing is. However, given the pace of development, I’m sure those things will get sorted out quite soon.
We’re going to Akademy
Yes, the Trolls/Nokians will be going to Akademy 2008.
The following developing Trolls will be coming: Andreas Aardal Hanssen, Daniel Molkentin, Daniel Teske, Harald Fernengel, Jesper Thomschütz, Kent Hansen, Lars Knoll, Marius Bugge Monsen, Matthias Ettrich, Olivier Goffart, Oswald Buddenhagen, Simon Hausmann, Thomas Cooksey, Thomas Zander, and I. Most of those had to learn how to use the new Nokia Travel Planner in the last week.
Besides those, there will be other Nokians coming from all parts of the globe. I know of people coming from Finland and from Brazil.
Hope to see you in Belgium!
And for those who can’t come to Akademy, save the date:
Qt Developer Days 2008
MUNICH, Germany: October 14th – 15th
REDWOOD CITY, California: October 29th – 30th
it’s official
In case you missed it, it is now official
Trolltech merges with Nokia
But do not be scared, my open source friends. This means that Qt and Qtopia will continue to be developed, and have even wider recognition that it is the greatest cross platform GUI toolkit on the planet.
I am sure there will be more press releases coming soon, so I won’t comment on anything else that might happen. But I can say this, this merger is a two way street. i.e. Nokia wants to learn from Trolltech and Trolltech can learn from Nokia.
What I wonder, is if Nokia can make a rubber boot for my phone. After all, it has been fairly rainy here in Brisbane this year.
Remember, “Trolltech has benefited greatly from the feedback the community has been providing while using Qt to develop free software. We respect the symbiotic relationship Qt has with the community and we wish to continue and enhance this relationship.”
So, keep on hackin’ Qt, Qtopia and Kde hackers, there’s good things around the corner!!
bye bye Trolltech…
Well,
This is my last post as a Trolltech employee. I have worked for Trolltech Pty Ltd, in Australia. since 2003. I can proudly say I helped Qtopia become more open, and fully GPL. It’s been a short 5 or so years, I have seen the Brisbane office grow from around 14 people to around 50, found my wife, had a son and daughter. A lot has happened in the past years. Ran ‘make’ more times that I want to think about. Got Qtopia running on all the devices I could. Yelled and complained and praised till I was blue in the face.
Tomorrow (Tuesday), I will be employed by Nokia, doing the same things I did today (well, maybe the day after next, tomorrow is the obigitory write-off “1st day”, BBQ and beer drinking).
It will be a challenging year ahead, I am sure both Nokia and Trolltech ^H^H^H^H^H^H^H^H Qt Software have things to learn from one another. I am personally wishing Trolltech’s seeds of open source will blossom Nokia into a greater thing.
So tonight, while I am unemployed, am going to live it up! and… uh… well… write some code (having small kids really saps your energy) and get more familiar with scratchbox2. (which thankfully uses a real cross toolchain).
I feel it is a bit like Christmas… So, if you talk to a Troll today, shake his/her hand and tell him/her thanks for making the world a more peaceful place.
hello Nokia!
Well,
I start work for a different company today, namely Nokia. Perhaps you have heard of them? No? Well, they used to make rubber boots but now make phones. Lot’s of them. They have a few employees. Lot’s of them. and now, a few more, thanks to the (more or less) peaceful assimilation of Trolltech.
Am I worried? A bit. The management structure at Nokia is overbearing, not like Trolltech’s lean and mean machine. I doubt I will see the CEO of Nokia getting drunk and wrestling with engineers any time soon. I doubt I will ever be called to a meeting with him to pick my brain about community matters, much less even get an email from him. I liked that about Trolltech. The openness, the friendliness.
Hopefully my boss will stop wearing his shoes so much. He used to go barefoot a lot more than he does now. I liked that about him.
Today, I start work for Nokia, sitting in the same desk (I hope), loging into the same machines (I hope), and continuing my work from yesterday (except today is the BBQ beer fest.. wweeeeeeeeeee!), on the Qtopia SDK, on the n8×0 and Neo devices. I still get to work with the greatest multi licensed cross platform toolkit ever - Qt. I get to use the greatest and Kool Desktop Environment - blackboxqt! heh and also - KDE.
Best of all - I get a new phone and some Nokia schwag.
I, for one, welcome our new Nokia overlords!
QtWebKit and Gutenbrowser
After many moons, I have started to work again on my personal project, Gutenbrowser. It is in need of much maintenance and love.
Since Qt finally has a good webview, QWebView, I can finally start working towards version 1.0! With very little work, gutenbrowser can now show Gutenberg Project etexts that come with images.
Since I have a macmini at home, I can distribute Mac binaries, as well as Windows and a few Linux embedded devices (Openmoko Neo and possibly Nokia’s n8×0’s Qtopia )
and with the help of Petter Reinholdtsen, fix a few bugs and be in the standard Debian distribution.
For those that do not know of the Gutenberg Project, there are over 25,000 free books available!
Decoration items, light and shadow effects
I’m studying how we can add light and shadow to widgets and items. I want to hear what you think :-). So I’ll just throw out my ideas and see what happens.
Light and shadow are special effects that follow and decorate items, and affect how they are rendered, at the same time as they’re a bit different from regular items / subitems, or subwidgets. For both light and shadow effects, there’s sometimes a need to render outside the item’s boundaries and blend into surroundings. For widgets, we then need to do something to break out of the box model… to make that happen. For inside-widget light effects, we’re limited to what we can do inside paintEvent() or inside the paint() function. I don’t know about you, but I think both light and shadow effects should be primary citizens of the scene graph, which essentially means they are also items. Stack-above / always-on-top (overlays) or stack-below / always-below items (underlays?).
Here’s a flash video showing a sample of what I’m working on. This is based on Graphics View.
The scene consists of 150 elliptoid items with shadows, and one light source that’s flying over it. It’s a bit psychedelic; anyone who loves colliding mice will love this. 
Haha.
Let’s start with shadows. In 2D, shadows can be pretty simple. Shadows can be thought of as transformed filled outlines of an object with a dark semitransparent fill and possibly fuzzy/blurred edges, stacked below the object itself. It has an offset, and/or an angle. The offset can be fixed for all items, or relative to one or more light sources. Ideally two shadows on top of each other don’t make a darker shadow, rather they blend with each other along the edges. Exact shadows are expensive to do accurately, and in many cases they’re completely pointless because they’re hard to see in the first place; at least the types of shadows we foresee being used in 2D / 2.5D UIs… Extreme shadows are cool but useless, subtle shadows, however, to me, are/can be beautiful. There seems to be a “market” for simple stupid fast shadows (e.g., bounding rect / bounding region based), pretty good medium-speed shadows (e.g., shape based), and custom shadows. And possibly perfect shadows (e.g., based on paint()) but I don’t really think that market is very big :-)).
As for how shadows are stacked, the easiest way is to just say that an item with a shadow always renders the shadow before itself. This works fine for most cases. But as soon as sibling items come close, and one’s shadow renders on top of the other, it starts looking wrong.
|
|
| Take 1: Sibling shadow overlaps | Take 2: Sibling shadows behind both |
It would be nice if I could set a shadow on our favorite “Drag And Drop Robot” without having lower leg shadows cast on the upper legs, or a shadow from the left leg draw on top of the right leg. I can see the need for both, but what would the API look like? And how would the items be stacked? My solution right now is to add a special flag to QGraphicsItem called QGraphicsItem::ItemStacksBehindParent (the child and its children are behind the parent), which is certainly one step on the way.
The other thing is how the shadow is placed. I don’t know about you, but I hate it how some presentation tools rotate the shadow relative to the item when you rotate and item that has a shadow on it. A picture says more than a thousand words:
|
|
No  Shadow follows item. |
Yes! Shadow follows scene :-)). |
It’s a bit complicated though because you want the shadow to follow the item, but you wants its offset to be done scene-relative. Turns out it’s just that the item’s local transform is prepended to instead of appended to the parent item’s scene transform. So I added a flag for that: QGraphicsItem::ItemBeforeSceneTransform. Btw this is just research, it’s not in Qt snapshots or anything.
Now light effects come in many different shapes and colors. Light can affect shadows, or it can just add a glow to an item. Light is typically represented by an abstract member of the scene, to which you can calculate distance and angle and apply a suitable effect to your item, or the background, and so on. In styling, we usually fake light big-time by just applying light and dark effects to our button bevels, or use pixmaps that look shiny and sparkly. Which, of course, is in many cases much faster than doing “correct lighting”. I recall once Zack Rusin and I were talking crap, I don’t know who brought it up but if the whole UI was a complex detailed 3D scene graph, lighting could come by itself (I think the discussion started with why buttons in RTL mode don’t have shadows cast as if the sun shine from the upper right).
For blend effects it’s also necessary to apply aftereffects that combine the source and destination. That can be done in two ways - either just via an offscreen buffer, or directly onto the destination device / framebuffer / or so. If we want blend effects I think we need some type of shader integration. Let’s not digress though.
So, ball in your court. What are your thoughts about light and shadow?
arora
Qt 4.3.5: Two steps back and one step forward
Earlier this month, we released the single, largest release of Qt since the 4.0.0 release two years ago. Qt 4.4.0 is the result of 10 months of hard work by the Trolls, including numerous distractions. And while it’s being digested by our clients and users, we’re working on Qt 4.4.1, which will include fixes for bugs that were already known at the time of the 4.4.0 release, as well as some that people have reported.
In the meantime, we take two steps back, to the 4.3.x series, and then one step forward: we’re releasing today Qt version 4.3.5. This release is meant for those who cannot upgrade to Qt 4.4.0 yet, but need fixes for some important issues. All of the changes done for 4.3.5 will be present in 4.4.1 and some are even part of 4.4.0 already.
This is the first time ever we’re doing a public release of the previous minor series. In the past, we’ve always stopped development of the previous minor series when the next one came out. Sure, we’ve done security fixes when needed and Trolltech Support continued to support clients using them, but we’ve never made a public release. So this is news for us too.
One of the main reasons that made us decide to release 4.3.5 was the sheer size of the 4.4.0 upgrade. Many customers are scared to take the leap. Not that 4.4.0 is a bad release — no, far from it, all indications so far are that it is a great release. (At least, the Trolltech head of Support hasn’t tried to kill me yet for it!) But nonetheless, we decided we would reassert our commitment to all clients and users despite all distractions, by providing them with one more 4.3 release.
If this proves to be a good thing, we may repeat it for the 4.4.x branch when Qt 4.5.0 is released, although we’re not expecting anything as groundbreaking for that release as 4.4.0 was. We also have two or three bugfixes up our sleeves in the 4.3 branch, which may lead to a 4.3.6 release if necessary.
Including the pictures of the Qt developer team again, since a few more people have been patched in.
|
|
| Oslo team | Berlin team |
doing it
It’s been a long time since I have blogged anything. Been busy finding a new house to live in, then moving house, then holiday/being sick at Waikiki in Hawaii. Waikiki is much like the Gold Coast here in Queensland, except people there wear shoes, and tops. Australia is much more baby/family friendly, although. My 2 years old son finally conquered his fear of ocean waves, and was happily swimming in the ocean. Now we just need to wait for summer here so we can go swimming at the beach.
Been working on Qtopia integrations on the ficgta02 and n810 and readying for the upcoming Qtopia 4.4 release.
In particular dynamic rotation. Still small things to be fixed up for Qtopia 4, as a late addition to the Qtopia 4 game. We used to have it way back in Qtopia 1 and 2, but for Qtopia 4 it was never ported or really thought about, as most devices we were developing for did not need it, or didn’t really seem sensible to have it. But the Neo and n800/n810 are different. In particular, the Neo, has no buttons, so it can be oriented in any direction.
Qtopia 4 is much more complicated than Qtopia 2, with theming, styling and all that jazz.
Qtopia on the Openmoko Neo (ficgta01 and ficgta02) is mostly working. The Openmoko folks have picked up on Qtopia on X11 porting/demo code we had done, and started working more extensively on it for the Neo phones. They plan on trying to meld Qtopia with Enlightenment stuff. Or at least make them work together. Who says Qt and Gtk can’t live together?
Qtopia on n800/n810 is coming along nicely as well. We made the n810 rotate whenever the keyboard is slid in or out. Being in portrait mode when in and using the few buttons it has that way. Probably the most difficult thing for the n810 so far was the keyboard driver, going back to the days of the Sharp Zaurus qwerty keyboard.
Other projects going on I cannot speak of, but they generally benefit Qtopia.
Gambas 2 2.6 released
QWidget vs. Graphics View (ding-ding-ding!)
I’ve always had a dream that Qt’s widget system would be based on a powerful 2D, or possibly even 3D, graphics engine, reaping all the benefits and optimizations that make games run fast. The reason is, coming from a 3D graphics background originally (alright, I was 16 at the time), I’ve always been puzzled by how poor application UIs perform, and how constrained they are, compared to the most basic 2D and 3D graphics engines out there. I think there are many reason for why graphics toolkits provide limited capabilities, and performance, and I’ve been studying this, hoping to help find ways for Qt to be better than the rest. If you ask me why oh why, be warned, I will talk all night.
I think I could get shot for saying this, but IMO widgets are monolithic beasts. Input, painting, clipping, geometry, events and all are almost always packed into just one class. And that class plugs into a framework that works in only one way. It’s hard to change the way a widget clips without introducing rendering artifacts (draw outside and try to update with the rendered region - oops, the dirty region is autoclipped to the widget rect). It’s impossible to know what a widget looks like without calling paintEvent(), which is a virtual function that might do something different every time it’s called. Multithreaded painting is extremely hard. It’s hard to make the widget paint outside paintEvent() in general. Couldn’t the widget just say what it looks like instead?
The main reason it’s like this, I think, is that UI toolkits’ graphics capabilities are just a hurdle in the path to the ultimate goal, which is to pull together UIs with a nice tool, perhaps targeting your favorite language, and with a cool style and the perfect widget ;-). IOW modeled vertically, after the concrete problem to be solved (which is generally speaking a good approach), and perhaps constrained by the capabilities of the primary target platform. I still think we can learn a lot from looking at UIs as a specialization of a 2D graphics scene API, rather than 2D graphics being an extension to a UI toolkit. We need to model our graphics the way that graphics works (both software and hardware), and not cling so much to a particular problem space. Make sense?
Qt provides both a high-level widget API, a low-level graphics API, and a “mid-level” canvas API called Graphics View. Graphics View is an example of loosening up the constraints of the high-level API, without exposing too many low-level problems such as geometry and dirty region handling. In a way it’s more a 2D graphics engine than anything else. It manages surfaces in 2D (or 2.5D, quasi-3D) space. Originally, we meant for it to be different from QWidget. Obviously, it’s a framework that’s meant for something completely different than widgets (vector graphics, charts, maps, IC design, large scrollable scenes, and so on). What we’ve learned, however, is that the two aren’t really that different. Why can’t I have 1000 widgets in a QScrollArea, for example.
So looking back a few years, you’ll see that we’ve made changes to improve QWidget. Without breaking compatibility of course (which is amazing in itself, shows how Qt’s architecture allows for significant internal changes).
Before Graphics View came out, in Qt 4.1, we loosened up one constraint in QWidget by enabling automatic background propagation. Now, widgets no longer had any default background (remember this change? how about QWidget::autoFillBackground oh, OK now you remember ;-)), and we were one step out of the box-model that widgets traditionally represent (btw when I use the term “box-model” I refer to a widget representing an independent rectangular region of actual screen real estate). Then, in Qt 4.2, we introduced delayed widget creation (DWC), which allows a widget to be constructed without an actual window handle. As part of the DWC work Paul, Matthias and a few others did for 4.2, they had to ensure that widgets had enough local state to independently represent what it otherwise had with a window handle, as without. Well, this had a ripple-effect. During the Qt 4.2 and 4.3 maintenance cycles, we discussed the fact that the only widget that really needs a window handle, is the top-level. With Qt 4.4, Bjørn Erik did some tough refactoring work (which some of us, me included, thought wouldn’t really be feasible), and gave birth to what we call Alien Widgets, the invisible behind-the-scenes beauty. Because of this, in Qt 4.4, a window and a widget are different, despite being the same class, in that the window signs a “contract” with the windowing system to register some screen real estate. This is the same now on all platforms.
Still, after this, you could see some strings that pull QWidget down. Painting outside paint event - using QWidget for screen shot captures, for example, required painter redirection. Each widget still constructed its own QPainter inside paintEvent(), and with it a separate paint engine, despite how all painting ended up in the same paint device: the QPixmap backingstore, which was associated with the same top-level window. Now in Qt 4.4, QWidget has a render-function, much like QGraphicsItem has a paint-function, and the window is, for a subtree of QWidgets, essentially the same as a QGraphicsView is for a scene. Puh.
Background propagation. DWC. Alien Widgets. Shared Painter. You see what’s happening? We’re on a mission. We’re closing the gap between QWidget and Graphics View. And we’re not done, there’s still more to come. There are some things that we cannot easily change, like QWidget’s clipping model for one (it’s opposite from Graphics View) [*]. And that Graphics View can’t make windows like QWidget (arguably, this is solvable though). Plus all our widgets are QWidget-based. Embedding the QWidget-based widgets into Graphics View using WoC is cool, but it’s just not good enough for full-blown exploitation…
Feature by feature, I must say the situation today looks surprisingly good. I’m looking forward to the day when I can simply assign a QGLWidget viewport as QWidget’s window. Or when I can load UIs from Qt Designer into Graphics View. Or in Qt 5, maybe the two are the same thing (the latter is usually only mentioned between some specially interested devs in Trolltech social events after consuming large amounts of beer).
That’s enough blabber for one blog post. I just felt like sharing what’s on my mind these days. This is btw all part of the research we’re doing in Development / Trolltech to support next generation UIs.
–
[*] QWidget is by default clipped to the intersect of its rect() and the localized exposed region before paintEvent() is called. QScrollArea has no explicit clipping features. Because most widgets don’t draw outside their bounds, item-imposed clipping should have been off by default (obviously expose-clipping is unavoidable for viewports that allow partial updates). And scroll areas should instead explicitly clip the widgets that intersect its edges (widgets outside shouldn’t be drawn, you don’t need clipping for that) (most 2D and 3D graphics APIs use subdivision instead, essentially real-time retesselation of the intersecting primitives to avoid clipping altogether). It’s extremely hard to change this in QWidget today without breaking compatibility. QGraphicsItem has the preferred model in place. But all our standard widgets are written using QWidget, not QGraphicsItem/QGraphicsWidget.
QtWebKit Development Update
As part of Qt 4.4 we have now made our very first release! 
Shortly before the release we finished merging all our changes back to the Subversion trunk branch, where we are working directly now. We will continue to maintain and bugfix the code in the Qt 4.4.x release series, but we try to make the changes in trunk first and then backport changes as they fit.
Our current goal is to catch up with the architectural changes that happened in trunk and maintain the layout tests. Holger for example fixed the HTML Canvas after some internal API changes. Ariya started working on Netscape plugins for Windows and Tor Arne I heard is polishing a secret feature he’s been semi-secretly working on for a while now in not-so-secret trunk. I heard rumors that he’s going to secretly blog about the secret feature soon, so stay tuned.
Big props also to Marc and the guys at Collabora for landing the initial support for Netscape plugins for the X11 Qt and Gtk ports in WebKit trunk! Great job!
On the application side Urs Wolfer’s Google Summer of Code project for integrating QtWebKit into KDE has been accepted. Congrats Urs! Feel free to stop by in #webkit and bug us if you have questions
Qt 4.4.0 fully released
That’s the moment we’ve all been waiting for… or dreading. We’ve worked for long months getting it done and you’ve all been asking for it. Some of you even realised it has already been available for a few days, unannounced… And now it’s finally, at last, there!
Last week, we had a sneak release to current customers. And now it’s on the Trolltech homepage for the world to see. To make your life easier, here’s a download button:
We’re quite proud of this release. It’s the most feature-packed release of Qt ever and certainly the largest release since Qt 4.0.0 itself. This release adds:
- The Windows CE platform
- The Phonon new module: multimedia integration
- The QtWebKit new module: web integration
- The QtXmlPatterns new module: powerful XML support
- The QtHelp new module: flexible help support
- The QtConcurrent framework: parallel programming
- A new network resource access stack
- Support for regular widgets on Graphics View
- Support for non-native windows
- Support for shared memory
- Support for inter-process semaphores
- Support for painting on auxiliary threads
- Support for atomic operations on integers and pointers
- Improved printing support
- A new Qt Assistant
- And much more, since I will never be able to remember everything we’ve done
Not happy with all of that, we’re also bringing you:
- A video showing our demos
- A downloadable version of the pre-built demos (Windows only)
- White papers on embedded development, web support, XML, user interface styling
Continuing with the tradition started with the past minor release, we bring you those who did the work:
|
|
| Oslo team | Berlin team |
Trivia: there’s someone on both pictures. Can you spot who?
Last day in Porto Alegre
Kevin and I are chilling out in the speakers’ room in FISL. Later today we’ll head back to Thiago’s place in Sao Paulo before we start heading home tomorrow. It’s been a fun week, and I’ve learned a lot. I can’t wait to come home and get my hands into code again.
I had the pleasure of meeting some fellows from INDT here, they showed my some amazing stuff they’d done, and I’m bringing home a bunch of impressions for those who’ll be working on improving our UI. Since this research is going to be interesting for so many, Kevin also asked me to submit a proposal for this year’s aKademy. I think I’ll submit one or two proposals and we’ll see how that goes. Maybe one about our UI research, and one about Qt’s widget internals. We’ll see.
Now there are only three legs left of my journey. Sao Paulo, Frankfurt, then Oslo. Travelling north, it’ll first get much warmer, then much colder again ;-). It’s around 12 degrees C at home, and my favorite season (Spring in Norway is quite amazing). Looking forward to coming home :-).
FISL first impressions
I am writing now from the Trolltech booth at FISL, where the KDE contributors have also taken up shop. It’s the second of three days and I’m already very tired. I was very surprised by the toll that booth duty takes in such a large conference!
FISL (International Free Software Forum, in its acronym in Portuguese) is held yearly in the city of Porto Alegre, of the southern state of Rio Grande do Sul in Brazil. It is probably the largest South American event and one of the largest in the world. Yesterday I’m told there were 7000 people walking by and today it’s probably going to be even more, since it’s Friday. This is the first time that Trolltech has a booth here, but technically not the first that it has had presence.
At several points in time yesterday, we had our 3m x 3m booth packed with people listening to my ramblings (or Knut’s, or Helio’s, or Josef’s more constructive speeches). Questions ranged from people who wanted to know what Qt was and if it could be used for their application purposes (”Does Qt have forms?” or “Do I have to know C++?”), to people who were asking about Qt 4.4 new features, such as WebKit and Phonon.
There were also people asking about KDE 4 and its current state. Hélio had a nice presentation yesterday showing the state of things. Today, Kévin Ottens from KDAB is holding an introductory course to Qt4 development. Later on, there’ll be a KDE-Edu presentation by Maurício Piacentini (the KDE Games coordinator) and one by Andreas Hanssen on the future of graphics development in Qt. He says it’s Qt 4.6 material…
We also had people asking about Java and other languages. I was pleased to be able to tell them about Jambi, but I think I need to learn I lot more about it. Thankfully, Helio downloaded and installed Qt/Jambi on one of the demo computers here. It’s packaged by Mandriva, so it was a matter of a few commands only.
What amazed me was how much crowd two books and one Greenphone attract. Lots of people asked us when the Greenphone would be on the market — to which we had to answer that it’s already over. They also kept on asking if we were selling the C++ GUI Programming with Qt4 books we had on display.
Things to remember for next time:
- Bring A4 or A5 leaflets with information on Trolltech
- Bring a set of small loudspeakers so that the Qt4 Dance video can be heard
KDevelop gets Kross scripting
One of the more heated points in the ongoing KDevelop team meeting here in Munich is the good old language war - while I love (and hate just as much) Perl, Alex likes Ruby, Roberto JavaScript and I’m sure we can find someone who prefers Python.
Since Revision 797621 of KDevPlatform, scripting via Kross is now supported. This allows everyone to write an extension to KDevelop in his favorite scripting language. Since I’m most familiar with QtScript (yes, I did forget all my Perl a moment ago), here’s an example KDevelop script:
function documentLoaded(doc) {
print(KDevTools.toDocument(doc).url());
}
documentController = KDevTools.toDocumentController(KDevCore.documentController());
documentController.documentLoaded.connect(docLoaded);
This little script will listen to all documentLoaded signals from the document controller and outpout the URL of the file once it’s loaded.
So, let’s load a file:
documentController.openDocument("test.cpp");
and watch the URL being printed to command line. The available scripting backend could already be used to implement a simple “switch header/source” plugin, that opens the corresponding *.h/*.cpp file when invoked.
For the moment, the “casts” using KDevTools are required as long as I don’t understand how to auto-convert meta-types in a script-independent way
My goal for this meeting - implement a version control system plugin completely in a scripting language, so it can be deployed without headache for all supported OSes.
Four down, ~six to go
Greetings from Helsinki airport. I came back from my visit to Milan (thanks Riccardo for arranging the sprint, it was great to be there!) at around 02:30am this morning. Now I’m waiting for my connection through Frankfurt to go to Brazil.
I chatted with Thiago, who’s there already, and he said it’s a good 28C degrees in Sao Paolo right now. Here I am with my suede leather jacket, long jeans and a sweater, my suitcase has only black t-shirts in it, no sun glasses and no sunscreen, feeling pretty silly. He-he!
Milano was fun, I think I’ll want to sign up for more of those events in the future. My idle task was optimizations in QGraphicsScene’s sorting and transform code (I’ve managed a 15-30x speed-up so far, will submit changes to main/4.5 some time when I come back, see patch below). There’s still more optimizations to come, I think I’m just in the flow with this stuff now. Fun to help out with the port to using QGraphicsWidget, and also with some work we did to speed up the SVG cache. Sorry that I couldn’t stay for the API review. :-/
I’m bringing some feedback home to our team in Oslo:
* QtSvg could use some optimization work
* It would be very nice if QtSvg covered the entire SVG 1.1 Tiny standard
* I should write a blog or a Qt Quarterly article (or both) about tricks to make graphics fast / like device space pixmap caching for static content.
Now I’ve been in Helsinki, holding a presentation about our ideas for improving widgets, theming, animations and the like. Fun and interesting! And now I’m headed to Brazil to do the same. Wee!
PS: Apply to Qt it you have problems with performance with deeply nested structures in Graphics View: http://www.andreas.hanssen.name/scene-speed.txt (no warranty!)
Free USB hub with coffee cup holder!
I’m happy to announce (no April joke this time) that every attendee to the KDevelop developer meeting in Munich will get a free USB hub (4 port) with integrated coffee cup lukewarmer! No more cold coffee, this wonderful device will make sure that your perfect brew will stay hot warm slightly above room temperature at all time:
There are still some free seats, please check the KDevelop wiki for registration info and instructions on how to get there.
Disclaimer: Cup not included in offer. However, coffee and tea are free during the meeting
Marble running on Windows CE
Hello,
Some of you might know the generic geographical map widget Marble that is part of KDE 4.
As already stated in Torsten Rahns’s Blog I started porting Marble to Windows CE.
Since Marble is a pure Qt application and does not rely on OpenGL the port is pretty straightforward.
The main problems were memory constrains, because Windows CE 5 only supports 32MB virtual memory. And of course speed is another issue. I had to reduce the complexity of the vector data set, because there is no tiling implemented, yet, and all the vector data has to fit into memory. The bump map is also significantly smaller than in the desktop version.
And now Marble runs on Windows CE as you can clearly see:
Marble on Windows Mobile 6.0 (America)
The Marble port proves that Qt really allows to port fairly complex application easily from the desktop to embedded devices. In this case the new Windows CE platform. It is also a good test case for stability of Qt for Windows CE.
Marble on Windows Mobile 6.0 (North Pole)
Marble on Windows Mobile 6.0 (Afrika)
Marble running on a ViewSonic Windows CE 5.0 tablet, also powered by an ARM cpu.
Marble in full action on a Dell Axim