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

A while back we announced the research project Qt Jambi AWT Bridge which allows you to mix AWT/Swing components and Qt widgets in the same window on Windows and Linux.

There were a few issues with the original version. The main problems were the fact that your window would be deactivated by the window manager when you clicked inside an embedded widget, some issues with unnecessary whitespace around the embedded components when you embedded AWT inside of Qt, and some people experienced a race condition which caused the embedded widgets to sometimes disappear.

The project has now largely been rewritten to be more robust, and both the window activation issues and whitespace issues have been resolved. If you sync the latest version from Subversion, you should be able to see major improvements. There are still some issues with keyboard focus (tabbing between the application widgets and the embedded widgets) which we are trying to resolve.

The sequence of commands to build has also changed. Please follow the following steps in order to build the project from source (for users of a binary package of Qt Jambi, we will try to get binaries for the bridge up at some point.) The following steps will only work if you have also built Qt Jambi from source.

Windows (Replace “nmake” with the “make”-application of your choice.)
set JAMBIDIR=\path\to\jambi\source\package
set JAVADIR=\path\to\java\sdk
.\generatorstep.bat
qmake
nmake

Linux
export JAMBIDIR=/path/to/jambi/source/package
export JAVADIR=/path/java/sdk
./generatorstep.sh
qmake
make

That should take care of building the native binaries. Then put Qt Jambi in your class path and compile all the .java files:

javac com/trolltech/research/qtjambiawtbridge/generated/*.java
javac com/trolltech/research/qtjambiawtbridge/*.java
javac com/trolltech/research/qtjambiawtbridge/examples/*.java

There are two examples in the com.trolltech.research.qtjambiawtbridge.examples package: QtInAwt and AwtInQt. These are the same as before, and show, respectively, how to integrate a Qt widget in an AWT frame, and how to integrate an AWT component in a Qt widget. Here’s a screen shot of QtInAwt:

The window here is handled by AWT, the two input fields and labels for the name are Swing components, and the entire bottom part is a layout created in Qt Jambi.

Please go to the project homepage for more information.

Distorting the geometry of an image with a specific periodic pattern can give the illusion of being underwater. This trick was for example employed in the very first version of Quake, either to oscillate the water surface or to modify the view when you jump inside the water. Apparently, it is not difficult to do that, even with pixel-per-pixel manipulation of QImage.

Check out the code from the usual place:

svn checkout svn://labs.trolltech.com/svn/graphics/dojo/underwater

It is recommended to build the program and see the effect by yourself, the following screenshot can hardly describe the animation. As usual, once the example is running (it would show the included bridge picture), you can change the picture by dragging an image (from local disk or a web browser, e.g. Flickr or Picasa Web) and dropping it on the main window.

Note: the snappers picture is from james_wicks, distributed under the Creative Commons Attribution 2.0 Generic.

Hi there. Introducing myself, my name is Friedemann Kleint, and I am one of the trolls hacking away at Qt Designer at the Berlin Office.

Today, I would like to draw your attention to the QFormLayout class. This is a special layout class suited to the common descriptive label - control arrangement found in many dialogs. It thas been developed in cooperation between Brisbane, Oslo and Berlin.

A typical form layout looks like this:

Note how the layout takes care of the label alignment according to the platform style. By the way, did you know that you can open several previews in different styles in Designer to compare them?

At first sight, QFormLayout looks like an ordinary grid. However, the layout also has policies for wrapping rows when it shrinks. For example, when setting the property rowWrapPolicy to WrapLongRows, we might get:

Let’s first have a look at the code. You might have created a such dialogs using QGridLayout, previously. This required some housekeeping of the current row. This is no longer necessary with QFormLayout using the addRow() convencience function. You don’t have to explicitly create the label, either:

QFormLayout *formLayout = new QFormLayout;
formLayout->addRow("Name", new QLineEdit);

For completeness, there is a setWidget() function which allows you to address single cells. It takes a row parameter and an ItemRole enumeration, which can be one of QFormLayout::LabelRole or QFormLayout::FieldRole.

In Qt Designer, you can create such arrangements as would in the case of a QGridLayout; you place the controls on a form and choose “Lay Out in a Form Layout”.

Hint: If you have existing .ui files containing such 2-column grid layouts and want to migrate them to the form layout, it might be sufficient to just replace the layout element <layout class="QGridLayout" name="gridLayout" ></layout> by something like <layout class="QFormLayout" name="formLayout" ></layout> (after making a backup copy, of course ).

It is also possible to create arrangements with controls that span the 2 columns. This let’s you add controls with long labels (for example QComboBox) or QGroupBox elements. It can also be used to partition the form layout into sections by using spanning QLabel elements:

In code, you would use the addRow() overload that takes just one QWidget* parameter.

In the upcoming 4.5 release, this functionality will also be available in Designer. Lonesone widgets on a QFormLayout get an active left/right resize handle that let’s you change the span:

The per-cell API of the QFormLayout uses the SpanningRole enumeration value of ItemRole to handle these rows.

Summarizing, the QFormLayout should be used whereever the typical descriptive label - control arrangement occurs. The dialog will then look correctly on a all platforms.

Time for another fresh example for the Graphics Dojo. This time I present a small tool that does nothing but showing the famous HSV cylinder. To give some realism, subtle blurred reflection is also added but can be easily disabled. Manual full-scene anti-aliasing is provided by the usual multisampling approach. Everything is done using pure QImage per-pixel manipulation along with some tricks, no OpenGL (or even its GLSL) is involved.

For the code, check it out using:

svn checkout svn://labs.trolltech.com/svn/graphics/dojo/hsvpie

Note that the tool is not optimized for speed (evidenced by lots of setPixel() calls) so there is definitely room for improvement. Some possible further enhancements left as exercises for the readers are interactivity (mouse dragging to change e.g. the depth of the pie) and threaded rendering (so that the application remains responsive, just adapt the Mandelbrot example).

Have some dojo-fun!

Hi there. This is my first blog post, so I guess introductions are in order; My name is Henrik Hartz, and work as a Specialist with Product Management in Troll^W Qt Software. In Product Management I do all kinds of stuff, ranging from working with requirements, specifications, product releases, meeting customers, thinking about the future of Qt, the list goes on.. Recently I’ve had the pleasure of focusing on WebKit.

WebKit is a fantastic technology. Being able to stick web content into your application is simply amazing, there’s just about anything out there you can show! And, a lot of people know HTML, so making use of this to add content to your application enables you to (ab)use your Graphic Designer buddies.

But, WebKit is so much more than just a way to show HTML in your app. You can actually do anything a browser can - and much more! Experimenting with WebKit over the last couple of months I’ve made an example that a lot of people seem to be interested in; Using WebKit to host a Google Maps component.

I wanted to show where our offices are located in the world. So, I started with a simple QStandardItemModel that would read in addresses from a txt file. In the constructor, we read in the text file - using the first field of the comma separated line as the display role, and the rest as the address stored in the UserRole;

QStringList addressLines = address.split(",");

QStandardItem *item = new QStandardItem;
this->insertRow(this->rowCount(),item);

item->setData(addressLines.takeFirst(), Qt::DisplayRole);
item->setData(addressLines.join(",").trimmed(),Qt::UserRole);

With this model in place, we simply set it on the list view of our GUI design (yeah, I like using Qt Designer - it’s fast!);

ui.treeView->setModel(new AddressModel(this));

In the GUI we’ve also placed a web view, which is pointed to a web page under our control. This page shows a Google Maps control. So here is the GUI with the address list and QtWebKit component;

This doesn’t do much on it’s own - so we promote the QWebView class to a custom component “Map”, defined by map.h in Qt Designer. This component has some additional services that allow us to update the map, specifically;

void geoCode(const QString &address);

What we want is to update the map based on the entries in the list view when they are clicked. We do this in a slot method connected to the clicked signal of my view. Here we can access the data of the item being clicked, extract the address and ask the map component to geo-code it;

void MainWindow::showItem(const QModelIndex &idx)
{
ui.map->geoCode( idx.data( Qt::UserRole).toString() );
}

The geoCode method will use QtWebKit’s capability of calling JavaScript functions in the web environment. Here we’ll use the Google Maps API to get Google to return a coordinate of the specified address in CSV format, using the asynchronous QNetworkAccessManager::get(const QNetworkRequest &request) API;

void Map::geoCode(const QString &address)
{
QString requestStr( tr("http://maps.google.com/maps/geo?q=%1&output=%2&key=%3")
.arg(address)
.arg("csv")
.arg("GOOGLE_MAPS_KEY") );

manager->get( QNetworkRequest(requestStr) );
}

In another method connected to the QNetworkManager::finished(QNetworkReply*) signal, we parse out the coordinate returned in CSV format from Google, and pass it to a method which updates the map component appropriately;

void Map::loadCoordinates()
{
QStringList scriptStr;
scriptStr
< < "var map = new GMap2(document.getElementById(\"map\"));"
< < "var bounds = new GLatLngBounds;"
< < "var markers = [];"
< < "map.setCenter( new GLatLng(0,0),1 );";

int num=-1;
foreach( QPointF point, coordinates ) {
scriptStr < < QString("markers[%1] = new GMarker(new GLatLng(%2, %3));")
.arg(++num)
.arg(point.x())
.arg(point.y());
}

scriptStr
< < "for( var i=0; i<markers.length; ++i ) {"
< < " bounds.extend(markers[i].getPoint());"
< < " map.addOverlay(markers[i]);"
< < "}"
< < "map.setCenter(bounds.getCenter());";

this->page()->mainFrame()->evaluateJavaScript( scriptStr.join("\n") );
}

In the final call, we tell QtWebKit to evaluate the JavaScript we have synthesized, and the web view updates with the appropriate location;

The snippets shown here are simplified to some extent, but you can find the complete source code here. Please remember to put the HTML for the map component on a server you control - and replace the GOOGLE_MAPS_KEY with your own key (you need to register and bind to a domain for it to work) in both map.cpp and index.html.

Enjoy!

After 4.4.0 was out I set aside some time to go though the feature requests for QTabBar & QTabWidget. After making a list of the most voted for suggestions I have implemented some features that will be in 4.5.0 that should make some developers happy.

In the past ten years the tab widget has gone from being something you see in a settings dialog to the widget that is the central widget of QMainWindow for many applications. Trying to use QTabWidget in the main window as it is in 4.4.0 has a number of shortcomings. One big issue is that if you maximize your application and move your mouse to the far right and try to scroll it wont because the mouse is actually over the 2px frame and not the scrollbar. I present for your enjoyment QTabWidget::documentMode which will only put the frame on the top with the tabs. Another very annoying problem for QTabWidget was that if you wanted to add a context menu or handle any event in the tab bar area you had to subclass both QTabBar and QTabWidget because the empty area was actually owned by QTabWidget and the tab bar widget was only as big as the tabs. Document mode will cause the tab bar widget to take up the entire space above the tab widget which will simplify a lot of code.

Looking around at what features people have implemented in their subclasses of QTabBar many have added some sort of hack to be able to either put a widget on a tab or the ability to paint a button. Doing this right, QTabBar now has a function QTabBar::setTabButton to let you put a widget on the left or right hand side of each tab. Taking this one step further there is also a convenience property
QTabBar::tabsClosable that when enabled will automatically add a close button to each tab. The close button it painted by the style using PE_IndicatorTabClose. When the close button is pressed the signal tabCloseRequested is emitted. Note that the location of the close button is also determined by the style so you can not guarantee that it will always be on the right hand side and the side with the close button should be determined by a call to the style with SH_TabBar_CloseButtonPosition. Custom styles that paint tabs themselves needs to be updated to take into account the space needed for buttons (see QStyleOptionTabV3).

When a tab is closed rather then always selecting the tab to the right there is now a
QTabBar::selectionBehaviorOnRemove property to decide which tab should be selected. The three included values are left, right and the last selected tab.

Another highly requested feature is support for the ability to move tabs. There is even a number of patches floating around out there that add many different moving schemes. A moveTab function was added, but taking it to the next level the property movable has been added which lets you drag the tabs around and as you pass over tabs they slide to their new position (i.e. animated sexiness).

Because animations are hard to describe I made a short video. In the video I first add a QTabWidget to a QMainWindow, turn on document mode, closeable tabs, and the moveable property. Then I preview it in plastique and drag around a few tabs. I start out using cleanlooks so it picks up the Gtk close button and then in plastique you can see it using the default button.

Lastly for applications running in OS X when using document mode the style paints the entire tab bar to match those tabbed applications like Safari and Terminal that are found on OS X. Below is a screenshots of a QTabWidget in a QMainWindow with a QWebView. With OS X it is very clear that the tab widget now goes to the edge of the screen.

Hope you all enjoy it. Some of the patches are already in Qt main, but you can find all of these in tonight’s snapshots. Let me know if you notice any issues with the new features.