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.

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

and not to forget about former Trolls

• Girish - OpenDocument support in KWord 2
• and playboy Zack’s talk on Gallium3D - Graphics Done Right

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.

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

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

As many of you know, I’m an OpenDocument fan, I love working on making KOffice rock, which is something I do at every opportunity. The work I do is mostly outside of the KOffice repository nowadays and others are picking up the slack. One really cool development is that I found some people willing to put some corporate funding into making our ODF compliance rock!

If you want to write some software and you want to maintain it for various years the best way to do this is to have regular testing in place to ensure that with further development the features you released in a previous release didn’t break. This is a common practice and the quality of your release is directly linked to the amount of testing you do. In the open source world the many users tend to work as testers, which is a concept that generally works pretty well. A much better solution is to have auto-tests. This is basically a program that does a certain task and checks the outcome for the expected values.

In KOffice we are working on improving out ODF compliance by first writing a test, and then making sure that the feature gets implemented. Before committing all tests ever written are ran and only when all of them (still) pass we can say the new feature is done. It should become obvious to anyone reading this that writing new software like this will create better software that is easier to maintain over time. Especially in open source where new people come and go on a regular basis.

I’m therefor extremely happy to report that Girish Ramakrishnan has so far created and made passing 51 61 OpenDocument Format loading tests. This in effect means we have lots of ODF features we researched what they should do (by reading the ISO specification) and then make sure we actually do that. Now and years from now they will do what they are meant to do.

The features we are testing are, for example, lists. That a document that is meant to have a numbered list with any sort of complex numbering load and show correctly. But sometimes we have some quite different test, things that KOffice never did before. In that case new features have to be added to KOffice. One such feature is the dropcaps. This is a feature that people that write newspaper style documents will love. Let me show a screenshot which explains it best.

For this new feature we have yet to add some dialogs to configure this, so to try it out I started OOo and loaded the odt doc in KWord. Which I admit is a pretty cool way to show how far we have come in the interoperability area

Update; updated number of passing tests.

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!

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?

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.

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.

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!

Qt 4.4.0 is released

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?

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

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

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

I’m preparing for an interesting trip… Finishing up Qt 4.4.0, as Thiago blogged about yesterday, I’m spending my time planning activites for 4.5 and 4.6. Input from everybody is crucial these days and months ahead; we want to hear first hand from you all what we should focus on. So I’m going on a trip to meet our fellows and users face to face :-). It goes something like this:

Oslo - Prague - Milan - Helsinki - Frankfurt - Sao Paolo - Porto Alegre - Sao Paolo - Frankfurt - Oslo

Thiago pointed out that I’ll be in four countries in just two days. One is a connection, so it doesn’t really count ;-). But I’m not used to traveling, and I prefer economy over business [*] ;-). I enjoy airtime, so it’ll be fine.

I’ll be in Milan for the April Plasma sprint. Hoping for quality time with some of KDE’s Plasma developers. I’m there to look and listen, hopefully I can help out with something. I’ll share some ideas we have for improvements to Graphics View and Qt in general, we’ll see what comes from that. Looking forward to beer in the evenings too of course ;-). Unfortunately (a slight communication error or lack of attention from my side) I’ll be there a day late, arriving the evening of the 11th, and I have to leave the evening of the 13th, so I’ll only be there for two whole days. Still, I’m very much looking forward to this event :-). Got my laptop, prepared to eat chips, drink coffee and coke, and just help out.

After that I’m heading to Helsinki to co-present some of our plans for Qt for a group of representatives of our future benefactors. At first I was intimidated by the upcoming acquisition. Now I’ve learned that there are some really cool people working for Nokia, they’re down-to-earth, they respect the work that we’re doing, and also the methodology and development culture that Trolltech is known for. Arriving at 00:55 that day (ugh!).

Then I’m going to Sao Paolo (Thiago’s home town!), having some pizza, staying over one night and then going to Porto Alegre to attend the FISL (9° Fórum Internacional Software Livre) to present how Qt is evolving to match tomorrow’s UI requirements across all platforms.

Oh and btw, our plans point in the direction of improving stability, quality, and performance of Qt as a whole. My sketchboard is also covered with ideas on how we can evolve the UI (thinking about styling, benefits and limitations our widget model, animation support, and more).

If you have small or large features you’d like to see in Qt, go ahead and open the threads on qt-interest, QtCentre.org and other forums. Get your ideas out, get feedback for them, and let us know about it.

[*] I’ve never flown business class ever before, and I’m proud of it!

Programming in groups requires you to use a source revision system. Its a fact; not doing it would be like crossing the north pole in your sunday clothes, it won’t be very successful. This shows; as long as people have collaborated in writing software, there have been systems to support this. I count 32 such systems on wikipedia .
Up until 2001 or so I used cvs exclusively. It did the job, more or less without loosing too much work. I started looking into distributed source revision systems, which looked a really cool idea that may give each individual programmer a lot more control over how he works, and how he can collaborate with his peers.
I went through TLA, got frustrated by the complexity, searched on and found Darcs. Fell in love quite quickly. Great idea, even better user interface. Unfortunately written in a language I never had the patience to go out an learn (haskell). Perfect romance setting, gives me what I need and I can never hope to fully understand it

Darcs was started initially with the idea that a distributed system doesn’t have to be more complex to use, just different from a centralized system. I have been part of the development of Darcs to the extend of working on user interface issues, writing clear language in the UI and other simple things like that.
Darcs has its share of technical problem, though. It doesn’t scale up well. Its basically unusable for bigger projects.

Flash back to the present. It feels like git is going to be the winner in this battle of programmer mindshare; on a technical level it certainly is the best there is. It scales up without effort and it is incredibly fast. Here at Trolltech various people are already using it every day. There is ongoing research to make it the default system in KDE as well.
Git, in my eyes, is the absolute opposite from Darcs, where one is bad the other rocks and vice versa. Git is technically superior; its basically the next generation in its field. Its got more features then you can wave a stick at, and its got mindshare and active development. The bad is that its reinvented the user interface, the in-line documentation is weak. The choice of command names arcane and inconsistent. Discoverability of features is basically a hit-and-miss.
Darcs, on the other hand, has not been strong technically but it has been developing a user interface (command line) over the last 4 years that is coherent+consistent, easy to learn, has lots of textual feedback while still being very feature rich.

Now, what to do! I like parts of both, but using either gives me headaces. The sum of the parts is a negative number in this case

So, like any good hacker, I started a new project to marry the two components. My project, which I call ‘VNG’ uses a normal git repository and expects git to be installed but using ‘vng’ you will find an interface designed much more coherently. Darcs users will feel right at home.
The project is very much in alpha right now; what is there works, but you’ll be using git for more advanced things. (and some not so advanced things).
I did find it time to make a nice announcement and call for developers that want to help out work on vng.

A short tutorial to get you started;

  $ mkdir ~/myproject
  $ cd ~/myproject
  $ vng init

You now have a Vng repository! Let’s do something with it:

    $ touch myfile
    $ vng add *
    $ vng  record -am "Initial import."
    Finished recording patch `Initial import.'

A simple ‘vng’ will give you the help output, which I’ll just paste here as a good overview what I already have;

Usage: vng COMMAND ...

vng version 0.22 (>2008-03-28)
Commands:
  help          Display help for vng or a single commands.
Changing and querying the working copy:
  add           Add one or more new files or directories.
  revert        Revert to the recorded version (safe the first time only).
  unrevert      Undo the last revert (may fail if changes after the revert).
  whatsnew      Display unrecorded changes in the working copy.
Copying changes between the working copy and the repository:
  record        Save changes in the working copy to the repository as a patch.
  unrecord      Remove recorded patches without changing the working copy.
Copying patches between repositories with working copy update:
  push          Copy and apply patches from this repository to another one.
Administrating repositories:
  initialize    Initialize a new source tree as a vng repository.

Want to help or try vng? The sources are on; http://repo.or.cz/w/vng.git
Either send me patches or upload them to the ‘mob’ branch (which requires no password) on repo.

Looking forward to your flames!

We use a lot of tools and applications when we develop Qt and Qtopia. Strangely enough, it turns out a lot of these tools are open source We’ve always been wanting to give something back to the talented developers of these tools, be it money or just praise. These tools make our working day better, more efficient and sometimes even FUN!

So, the engineers here are at Trolltech decided it’s time to have an annual award where we vote and select the best open source development tool available out there. In other words: The Trolltech Open source Development Award.

So here are the finalists for the 2008 awards. They’ve all been nominated by at least one Troll, so there is at least one person out there that loves your tool

The price will include money AND a signed T-shirt. But regardless who wins we’d like to thank the developers of the tools below: You make our day a little bit better. THANK YOU!

	Coding requires music. Music requires a player. This is the one.
	It’s everywhere. So are we. It’s a match made in well, maybe not heaven but pretty close?
	All the other revision control systems are easier to use - but this one is more powerful.
	When we don’t code we chat. But don’t tell management. (They use Mirc)