As you may have noticed, the year is almost over. I like the name Trenton is using for it: Space Christmas. This is usually a time when people aren’t working on their day-time jobs, so they are left with some free time to do other stuff. For example, go to the beach or the swimming pool, enjoy the sunshine, etc.

What? You don’t do that? Yeah, I guess it’s my Southern-hemisphere-centric view talking. It’s 32°C in São Paulo right now, so I can only imagine how warm it is at the beach (75 km away and 800 m down).

Anyways, like I was saying, this is a time of the year people start working on other stuff. That is true as well for me. I have decided to actually start working on the Subversion-to-Git conversion tools I’ve been talking about for months. So you can expect a few blog entries from me in the upcoming weeks how the progress is going.

But I’d like to explain first of all why I chose Git. And the short version is: because I’m lazy. Yes, the reasons are entirely personal and not technical, so please don’t post a comment accusing me of that. I already know.

The funny thing is… I didn’t choose Git. I chose Mercurial at first. For two reasons, all of them showing my laziness and stubbornness:

1. it was installed already on my laptop, because I had had to use it to pull the Em2880 v4l-dvb driver for my USB TV tuner.
2. because everyone was talking about Git, I wanted to be different

So, sometime in May this year, I decided to convert my local SVK tree of the Qt snapshots. SVK is a good program, written entirely in Perl on top of the Subversion libraries. I suspect that Perl compiling all of that code on-the-fly is a bottleneck, because after a while SVK was too slow for me. Therefore, I chose Mercurial to convert to.

Besides, I figured that, since everyone was talking about Git and using it, I might as well provide another point of view.

Unfortunately, my laziness reared its ugly head again: I failed to make heads or tails of the conversion tool that Mercurial uses. And people say it’s an easy tool, so I must be really lazy.

At the urging of a fellow Troll working on WebKit (though technically I wasn’t a Troll at that date) and a fellow KDE developer trying to convert the entire KDE repository, I decided to give it a try. And after a few fixes on Chris Lee’s svn-fast-export, I managed to convert my SVK local repository to Git! [Note: I now know that tool to be extremely limited and will produce erroneous conversions in some cases]

Since then, I have found more reasons to stick with Git, including the fact that I’m using Git inside Trolltech to avoid using Perforce. I won’t enumerate them here because they are technical. [Who cares about technical reasons backed by numbers? We should all make decisions based on personal feelings! The bikeshed is always blue!]

So last week I started working on a rewrite of svn-fast-export, which I called svn-all-fast-export because it creates multiple Git repositories. It’s a very powerful tool, but not very easy to use. It took me 2 days to finish writing the rule file for the import of the KDE main modules.

But I’m happy to say I’ve reached the third milestone in the conversion process. For those lazy to click the previous link: I managed to convert the KDE modules “arts”, “kdesupport”, “koffice” and “KDE/*“, with all official branches, to Git. For the details, click the link.

PS: have you noticed how I managed to link to 5 different revision control systems in this blog?

In Norway (and I guess around the rest of the world) now is the time between Christmas and New Year’s. The Norwegians call the time romjul. Rom in Norwegian typically means rum, the distilled beverage. However, rom can also mean “room” or “space” and that’s what it means in this context, the time between Christmas and New Year’s Day. Therefore, I affectionately call this time, “Space Christmas” hoping to evoke a campy sci-fi feel for the time, usually to some Norwegians chagrin. It seems to have stuck though as I’ve heard Norwegian in the halls of Trolltech use this phrase as well.

Anyway, the point is that this is traditionally a down time when people are out doing other things. Sometimes people do check blogs during this time though, so I decided to spotlight on a couple of things in Qt/Mac that are in Qt 4.4.0. Both of these are little things that are no where near as earth-shattering as any of big features, but I think they are worth mentioning.

The first is something that I’ve sorely missed in Qt, and others have as well too I’m sure, proper support of proxy icons. A proxy icon is a nice feature of Mac OS X that allows you to put an icon in the title bar of a window to act as a “proxy” in drag operations. This turns out be extremely useful once you know about it. You can also do a Command+Click on it and it will show a pop-up menu with a path to where the item is on disk. This is very handy too when you want to make sure which file you happen to be editing. More information on proxy icons can be found at Apple’s Developer Website.

Astute readers of Qt Quarterly will remember this article where I talk about some of the events that were added in Qt 4. One was the Qt::IconDrag event, which allowed one to emulate the proxy icon. However, it was only emulation and it was a lot of work for something that I think most people wouldn’t bother doing unless they really were concerned about their Mac OS X application. I know of one person, besides me, that actually did this.

So, we needed an API that allowed you to get set the proxy icon, but also was worthwhile for people to use it in cross-platform code. It seems we found it with QWidget::windowFilePath property. This will associate a file path with a window, on all platforms it will do also set the window title of the window to the filename including the [*] token so that it behaves well with QWidget::windowModified property. If you still want control over the title bar, that’s OK, just set the QWidget::windowTitle property and it will use that. Oh yes, on Mac OS X you get the added benefit of a proxy icon if the path exists.

That means that you can take out old code like this:

QString shownName;
if (fileName.isEmpty())
shownName = "untitled.txt";
else
shownName = QFileInfo(fileName).fileName();

setWindowTitle(tr("%1[*] - %2").arg(shownName).arg(tr("Rich Text")));
setWindowModified(false);

With something like:

QString shownName = fileName;
if (fileName.isEmpty())
shownName = "untitled.txt";
setWindowFilePath(shownName);
setWindowModified(false);

Granted it may not seem like much, but if you’ve written a lot of application saving and loading code, it’s less to write and you get a real proxy icon for free (as shown below) with no code on your part.

So, that’s the first thing and anyone writing Qt code can take advantage of it. The second is very Mac OS X specific and shouldn’t affect the vast majority of users out there, but co-workers have asked about the change, so I thought I would say a few words on it here. In the course of my bug fixing, I changed Qt applications to no longer make themselves the front application anymore on start-up. For most applications that you launch via Finder, the Dock, Xcode, or Launch Services (which implies QDesktopServices) you should see no difference. If you are launching an application by executing it directly, you may need to tell it to raise if you want that application to take precedence over the current application. This is to be more in line with all the other applications on Mac OS X (feel free to experiment). The main idea is not to grab focus away from the main application, which can be annoying. If you really want to people to turn their attention to your app you can use something like QApplication::alert which will bounce the icon on the dock on Mac OS X and do similar attention grabbing tricks on other platforms. This at least allows people to finish their current thought before switching to that application.

Anyway, there’s a spotlight on some things to expect in Qt 4.4. I hope your find use for them.

Happy Space Christmas!

Its almost Christmas 2007, and some months ago I moved to this country where I actually have a proper chance of having a white Christmas. Its already pretty white, really. Mostly due to being quite cold, not so much due to snowfall.

As you may know I’ve been working on my favorite OpenDocument implementation for some years, enjoying myself and pushing for this open format that allows information access for all. I’ve also been a member of the Technical Committee of the OpenDocument format, for quite some time now. Which proves to me its really an open standard, its cool that a lone coder that I was back then can have a vote in deciding the direction of the format.
So, you can imagine that I was pretty happy that just a couple of months after I moved to Oslo that my country of origin decided to have ODF as its official standard, stating that any MS format was not good enough.
Now imagine me laughing like a mad cow (with a party hat on) when I read the news today that Norwas, my new ‘home’ country, did the same!

Just a couple of days ago I looked out the window at work and noticed that, actually, its a pretty stunning view; so I think I can continue the trend that I have seen various people set to post a picture of “what I see when I’m not actually working”

To all, have some great holidays and I wish you a fantastic 2008.

I’m pleased to announce that the Qt 4.4.0 Technical Preview package is released. This is the first package release of the Qt 4.4 series and is packed with new features. For those of you who have been following the blogs on Trolltech Labs, this is no surprise for you.

But for those who have been, somehow, sleeping for the past 6 months, here’s a summary of what you can find:

• WebKit integration
• Phonon integration
• Enhanced XML support (QtPatternist project)
• Concurrency framework (QtConcurrent project)
• Interprocess communication framework
• Widgets on GraphicsView
• New help system
• Improved printing support

(More information at The Sneak Preview page)

Technical Preview releases are meant as a first peek at the upcoming technologies in the next minor release. Unlike the last Technical Preview we published (4.2.0), this time the technology has been available for some time on our public Bleeding Edge snapshots. So the 4.4.0-TP1 release is our announcement that that technology is now maturing and is ready to be tested by our users.

Packages, as always, can be downloaded from our FTP servers and mirrors. Point your browsers to http://trolltech.com/developer/downloads/qt/qt44-preview-download to find the closest mirror.

This release is brought to you by the hard work of all of the Trolls. I would like especially to thank the Oslo and Berlin teams (who are now over 40 engineers — meaning we will have to update the group photo) who worked really hard to finish all of the features above (and more) in time for this release.

Happy holidays for everyone. More cool stuff in 2008!

Since Qt 3.1, Assistant hasn’t been changed that much. In fact, I looks and works almost the same way as it did in Qt 3 times. We have received many suggestions for new features but were not able to implement them since most of them wouldn’t work well together with the Assistant structure, meaning they would have required fundamental changes to the code base. Now, for Qt 4.4. we are finally making a step forward by introducing a completely new help system.

The problem with the old Assistant as custom help viewer was that most people wanted to customize it more than it was possible. Some didn’t want the side bar at all, some others wanted it to be shown on the right instead of the left side and others wanted to have only the table of contents or indices shown. We also received suggestions to make only some of the menus or toolbars visible. Combining all those customizations would have added a lot of complexity which, in the end, may not even have satisfied all customers. That is why we went for the solution of providing a help library which offers the most important components for online help. The new Qt Assistant is basically just a reference application on top of the help library.

The new help library, called QtHelp, can be used for generating online help as well as retrieving its contents. The task of the retrieving part should be quite clear, but what about the generation part? Well, in contrast to the old Assistant, the new help system does not operate directly on html files any more. Instead, a new binary help file format was introduced which contains all the html files in compressed form along with the table of contents and indices. This should significantly ease up deployment since only one file has to be taken care of.

There are two ways of retrieving and displaying online help, either by using the help library or Assistant. Assistant, at first sight, looks pretty much like the old one, but having a closer look will show some differences. First of all, it is now possible to filter help contents according to their associated help attributes. This is especially helpful when having more than one (yes this is now possible as well!) Qt reference documentation installed. Secondly, navigating through the help contents can also be done by directly entering an url in the address bar. However, the most important fact is that Assistant does not contain any hard coded references to Qt documentation any more. So, every custom documentation integrated in Assistant has now the same possibilities, but also restrictions, as Qt documentation has.

The entire concept of having profiles has been given up in favor of using help collections. The main purpose of a help collection is to collect or reference one or more Qt binary help files. In addition, it can store nearly any data. In case of Assistant, the current help filter, the url of the currently displayed page or the location of its dock widgets - just to mention a few - will be saved. This removes the need of storing anything in the registry or .ini file which eliminates possible side effects seen with the old profiles approach. So, starting Assistant with a different help collection does not only change the set of help files but may also change its visual appearance.

The possibilities to change the visual appearance of Assistant are pretty much comparable to those existing in the old Assistant. However, some new ones like showing or hiding indices, bookmarks or table of contents were added.

Using Assistant as the help browser for an application saves a lot of time and effort. The downside is, that even though Assistant allows some customization it might still be too restrictive for some users. If this is the case, the help library should be deployed.

The help library provides models and views for indices and the table of contents, classes for full text search, functionality for accessing context sensitive help as well as functions for retrieving the actual help contents (usually html files). With the help of those components, it is easily possible to either implement a stand alone help viewer or, more conveniently, embed online help directly in an application.

Now, I guess it’s high time to let you know where you can find all this. Well, it has been integrated to our code base and you can get it by downloading a daily snapshot. Examples of how to use the QtHelp API (not 100% finished yet) can be found in the examples directory or in the Qt reference documentation.

The new Assistant is started by executing “assistant_new” (will be renamed). Since the new documentation format is not part of the daily snapshot yet, you have to either generate it yourself or download it from our help server. To generate it, simply call “make qch” in the root directory of Qt. Once the script is finished, restart Assistant and all Qt documentation will be shown.

Instead of generating the documentation yourself, it is much faster to download it from our help server. The help server can be accessed by opening the Edit|Preferences dialog in Assistant and activating the “Documentation” tab. Then select the “Download from Help Server” option from the “Install…” button. After a moment you’ll see a collection of currently available Qt documentation files. Select the ones you’re interested in and press “Install”. That’s it!

Hm, that title sounds funny with no associated context.

We’re implementing popup support in Graphics View. This is the result of an outstanding bug, or rather essential missing functionality, in the Widgets on Canvas project: support for embedded popups. I.e., popups that pop out of widgets that are embedded into a QGraphicsScene. Such as the QComboBox popup list, the QMenus of a QMenuBar, the context menu in QLineEdit. I could go on. Popups are everywhere! (AAaaarggh….) The bug is easy to see. Add a combobox to a scene, then click on it. As of a few days ago, the popup will show up at the right spot. But you’ll soon uncover the problem. It’s not a popup. It’s just a widget. And uh, plain widgets aren’t half way as cool at being a popup as popups are.

#include <qtgui>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));

    QComboBox *box = new QComboBox;
    box->addItem("Mandag"); box->addItem("Tirsdag"); box->addItem("Onsdag");
    box->addItem("Torsdag"); box->addItem("Fredag"); box->addItem("Lørdag");
    box->addItem("Søndag");

    QGraphicsScene scene;
    scene.addWidget(box)->show();

    QGraphicsView view(&scene);
    view.show();

    return app.exec();
}

This is crazy, when you think of it. First we thought QGraphicsWidget would be fine. From a framework POV, it made perfect sense. We add support for layouts and widget-like properties, and you can write your own widgets to put inside a scene. Then some bright fellow said “what about widgets people already spent time writing, do they have to _port_ them to QGraphicsWidget?”. We all knew the answer, which was an undisputable “yes and no”. Yes, you can, and that should be quite easy, but no, you shouldn’t have to. Making basic things easy, and advanced stuff possible, is a central design philosophy that swirls around in our minds more often than what’s good for us. Then some sucker ends up saying what everyone was thinking, (but couldn’t quite grasp so they chose not to say at risk of being held responsible for some major mistake later on,) which sounded something like “….a proxy widget?”.

Why on earth does the popup show up there? Wait, windows use global coordinates… and the popup adjusts to the current screen’s available geometry….

Yeah, a proxy widget. You know, just “plug it in!”. Ehem. Everybody nods and goes “that makes perfect sense, but,…” and then you see everybody thinking like crazy, before one of our brightest people suddenly breaks and tilts his head to the side, a spring popping out of his ear. Everyone wants to say something, everyone knows a proxy is a can of worms, but some silly person goes “hey, how hard can it be?”. And you know what, we really just can’t get enough of those people. Sometimes I like to think that many of mandkind’s greatest achievements come from people with a sudden unexplained lack-of-insight, inability to foresee the future, and just plain stupid. It’s like building a house. Everyone knows building a house is crazy, it’ll take way too long, cost more than you have, mess up your relationship, but still some people go “Look sweetheart, it’s just €175000 for the house and another €150000 for the lot!”. And hey, you get a house. Which is great ;-). And have more kids, and you know.

So the project starts, and when it reaches its successful end, everyone, (including the stupid entrepreneur,) wonders how on earth this project could succeed.

Hah! Anyway. Popups! Yes.

What’s the big deal with popups? Popups imply explicit and implicit mouse grabbing, event replays, nesting popups (i.e., nesting grabs), grab-on-show, release-on-hide. Window positioning (converting QWidget global screen coordinates to QGraphicsWidget local parent coordinates). Delete/hide/remove/deactivate/unfocus/disable while grabbing? Implicitly? Explicitly? What if you grab while grabbing? Ungrab without grabbing? You grab the mouse and some other widget does the same, then the other releases the grab. Or better yet, releases _your_ grab. Should the scene propagate the grab to the view? [*] It’s one hell of a state machine! I’m losing sleep thinking about cases where somebody’d explicitly release a grab that some other widget has implicitly gained from a simple mouse press. That’s a silly reason to lose sleep ;-).

Of course, it’ll work, that’s almost the annoying part. When it’s done it’ll work just fine. No bells ‘n’ whistles, just a darn popup. It’s just such a can of worms.

Now that’s more like it!

[*] No, it probably shouldn’t

Update 2007-12-20: Here’s a patch that implements popup and mouse grab support. It’s a bit broken, but the basic functionality is there.

Here are three good things for you while you’re all waiting for Christmas to kick in

1. We’ve released the second technology preview for Qt/WinCE, and
2. We’ve added support for Windows CE projects in our Visual Studio Integration for 2005
3. There are videos from Developer Days 2007 uploaded!

Second technology preview of Qt/WinCE

Since the last technology preview we’ve been working on moving Qt/WinCE from using Qt 4.3 to Qt 4.4. We’re basically done with that and thought this would be a good time for another package. We haven’t made a super friendly installer this time (no worries they will be back for later releases) but it’s still just the regular three-step:

1. Configure the package
2. Set your paths to your SDK
3. Build

Here is basically what’s new in the second preview called “Siesta”:

• Upgraded to Qt 4.4
• All examples and demos now compile and run for Windows CE
• The OpenGL module now supports OpenGL ES on Windows CE
• Added example for OpenGL ES
• Added support for QtConcurrent and QtXmlPatterns
• Visual Studio integration now supports Qt/WinCE
• Several improvements and bugfixes

Now if you want your dirty little hands on the package simply join the preview mailinglist for Qt/WinCE by sending a mail to:
qtce-preview-feedback-request@trolltech.com with the subject: subscribe

Of course, If you’re already on the list you already got a mail on where to get it.

Visual Studio Integration for 2005

One of the things I mentioned above, is that our Qt Visual Studio integration now also support creating Qt applications for Windows CE. This screenshot (click for a larger image) shows a Qt application designed in Qt Designer embedded in Visual Studio 2005 and then compiled and run on a Windows Mobile 5.0 emulator. If you want to try out the integration as well, just join the mailinglist as I said above - and the download info is provided to you.

Developer Days 2007 videos

Andreas tries to summarize his speech explaining the design and use of the Qt Network classes Interesting stuff here, for example towards the end he explains how easy it is to create secure connections with SSL in Qt.	A complete talk here from Girish (I guess he didn’t get the memo we were doing summaries ;D). Girish talks about how you develop using Qt with hints and tips specifically towards developing on the Windows platforms. Interested in how to make your application Vista certified? Want to hear about deploying Qt applications?	Kent has a talk here “loosely based” on his Developer Days talk about Qt Script. Puppies and kittens included!
Thierry here describes and shows the usage of the new Multimedia system coming in Qt 4.4.0. Some pretty sweet coding examples in the end showing how easy playback of audio or video, or both is.	Volker talks about how to make Qt play well with others, and how to make others play well with Qt Ever wondered if your Qt include statements should come before or after 3rd party ones?

The temperatures in Oslo have been dropping rapidly in the last few days, we’re well below zero now. The same applies to Qt where Thiago opened the fridge of feature freeze. I like how things fall into place :). Actually I have the same feeling with QtWebKit right now. The pieces of the puzzle are falling together, with lots of really good progress:

• We have integrated a copy of WebKit into the Qt sources and we’re updating it frequently.
• Shortly after the integration Friedemann, one of the fearless Designer hackers, added a plugin to embed WebKit into Designer, along with support for QUrl properties. See the screenshot below :).
• Lars and Holger finished the separation of QWebView and QWebPage. The latter is now a standalone QObject that allows embedding WebKit into non-QWidget environments.
• Michael Goddard of the TT Brisbane hackers started working on improving the QObject bindings inside JavaScriptCore, to make them behave like QtScript’s bindings with regards to signals & slots, properties and child objects. You can follow the progress in the branches of our public git repository.
• Holger fixed lots of bugs in the event handling. The Web Inspector works much much better now.
• We have written a little demo browser application to show the use of QtWebKit. It’s in demos/browser in Qt and this blog post was written using it :)!

Qt Jambi is all about breaking away the barriers between Qt in Java and Qt in C++. In fact, ideally you should be able to sit inside of either language and throw anything you want over to the other side, and somewhere along its parabolic path over the wall, this thing should magically transform to whatever the destination expects it to be. In that sense, Qt Jambi is kind of like Shakespeare futilely trying to marry a Capulet with a Montague (a plague o’ both your language designers!)

Definitely, there’s a lot of drama and tragedy involved, and there are certainly always things you can throw over that wall which anyone sitting on the other side will consider mysterious and meaningless. Most of the time, though (and the emphasis is very much on “most”) this works. Despite the many differences between the two programming languages, the APIs in Qt Jambi are almost identical to the C++ APIs, and, most importantly, the intention of the APIs is intact.

Right now, though, I want to focus on one thing which has so far not been supported: the Qt meta-object system. The meta-object system is an extension to C++ which adds introspection, dynamic method invocation and similar concepts to the language (which otherwise lacks any such features.) It is also the basis of the signals and slots inter-object communication mechanism which is featured heavily in both the Qt and Qt Jambi APIs.

We never implemented an equivalent of the meta-object system in Java. The main reason for this was, quite simply, that it wasn’t necessary. Java already has a more or less complete reflection API with all the meta-info you could ever ask for. Thus, we decided to implement signals and slots in Java on top of Java’s reflection API, and create a small binding layer in between which ensures the grittiest of the details work (emitting a signal in C++ emits the equivalent signal in Java etc.)

Still, we lacked one gritty detail: In some cases, Qt relies on introspecting objects through the meta-object system without going through the signals and slots mechanism. An example of this is when you register a mandatory field in a wizard. In this particular case, Qt Jambi currently does not support custom widgets as editors for the mandatory fields. There are very few places in Qt where this is actually relevant, but even so, in principle it’s a pretty big gap, so following our quest to fill as many holes as possible, in Qt Jambi 4.4 we will introduce the fake meta object.

As you can see from my illustration of what a screen shot of the fake meta-object would look like, if it was indeed possible to take a screen shot of it, it is not all that different from the regular meta-object. The main difference is that the fake meta-object is generated at run-time rather than be a statically compiled unit, and also that it may at some point rob a train using only dynamite and a hot air balloon. We generate the meta-object on request, and only once per class, and only for user subclasses, as all the C++ classes will already have proper meta-objects of their own. For compatibility with the general expectations Qt has to meta-objects, we also convert all Java signatures into C++ signatures before stuffing them into the fake meta-object. Of course, not all Java classes have C++ equivalents known to us (any class featured in the type system used to generate the Java code is handled automatically), in which case we use the JNI type jobject as a general fall back, meaning that you can potentially use this together with other JNI-based frameworks.

So, in conclusion: In Qt Jambi 4.4 you can, among other things, look forward to cool-looking beards and even more complete mappings of the Qt APIs. The fake meta-object also allows us to remove a bunch of hacky hacks e.g. to make Java classes blend in with Qt Designer (you don’t want to know) so expect it to give a general boost in stability and readability as well. We really like it, hope you will too.