For a long time the standard layouts shipped with Qt’s have been built around the concepts of linear and grid layouts. In the QLayout regime they are represented as QBoxLayout and QGridLayout. In the QGraphicsLayout regime they are represented as QGraphicsLinearLayout and QGraphicsGridLayout. We therefore started early this year with research on a new layout. The efforts of that culiminated into the QGraphicsAnchorLayout.

Motivation

We have quite often seen that the existing layouts in Qt can not always do what you want with just one layout. Take for instance Qt Linguist’s “Find dialog”.
The dialog is made up of four box layouts and one grid layout for the checkboxes inside the groupbox.

(note that Qt Designer does not illustrate the layout inside the groupbox or the toplevel layout)

In addition, in order to achieve this simple arrangement it uses three levels of nested layouts.
Luckilly, if you design it in Qt Designer it is quite easy, but you might not get it right at first attempt. Of course, doing it programmatically makes it even worse. The result are probably far from how a UI designer would specify the arrangement. We think that an anchor layout will narrow that gap in a lot of cases.

Concept

The QGraphicsAnchorLayout is a very flexible layout, yet the concept is simple. By creating an anchor between two edges of two layout items you are giving the anchor layout a constraint to fulfill. In the simplest case you are just saying that the distance between the two layout edges should be a fixed distance. You can do this with the left, right, top, bottom and the “center edges” of any layout item. You can also have an edge that has several anchors connected to it. This is not possible with linear layout and it is partly possible with a grid layout. This allows you to build up the structure the layout should have. The layout will then try to fulfill the constraints you have given it by potentially growing or shrinking the layout items. You can also configure each anchor to grow or shrink if that is preferred.

The API for configuring the layout structure reflects this concept. The addAnchor() function is all that you need to configure the structure of the layout, but we added some convenience functions for anchoring corners (surprise, addCornerAnchors()) and for fitting the size of an item to another (addAncors()). Thus, the following code will ensure that the left edge of item findEdit is always connected to the right edge of the item findLabel. In this case it means that there will typically be a bit spacing between the items, and the spacing will always be the same.

   anchorLayout->addAnchor(findLabel, Qt::RightAnchor, findEdit, Qt::LeftAnchor);

You can also anchor an item to a layout edge. If the edge of an item is anchored directly or indirectly to a layout edge, it’s geometry will react to changes in the layout geometry:

   anchorLayout->addAnchor(anchorLayout, Qt::LeftAnchor, findLabel, Qt::LeftAnchor);
   anchorLayout->addAnchor(findLabel, Qt::RightAnchor, findEdit, Qt::LeftAnchor);

Of course, you can also anchor items the same way in the vertical dimension.

Now, with this brief introduction we can go back to Qt Linguist’s “Find Dialog” example as I gave above.
It turns out we can make the same arrangement with just one anchor layout.

This is how the code could look like:

    QGraphicsAnchorLayout *l = new QGraphicsAnchorLayout;
    QGraphicsWidget *w = new QGraphicsWidget(0, Qt::Window);
    w->setLayout(l);

    // label, line edit and "Find Next" button
    l->addCornerAnchors(l, Qt::TopLeftCorner, findLabel, Qt::TopLeftCorner);
    l->addCornerAnchors(findLabel, Qt::TopRightCorner, findEdit, Qt::TopLeftCorner);
    l->addCornerAnchors(findEdit, Qt::TopRightCorner, findButton, Qt::TopLeftCorner);
    l->addCornerAnchors(findButton, Qt::TopRightCorner, l, Qt::TopRightCorner);
    // group box
    l->addCornerAnchors(l, Qt::BottomLeftCorner, groupBox, Qt::BottomLeftCorner);
    l->addCornerAnchors(groupBox, Qt::TopRightCorner, findEdit, Qt::BottomRightCorner);
    // cancel button
    l->addCornerAnchors(findButton, Qt::BottomLeftCorner, cancelButton, Qt::TopLeftCorner);
    QGraphicsAnchor *anchor = l->addAnchor(cancelButton, Qt::AnchorBottom, l, Qt::AnchorBottom);
    anchor->setSizePolicy(QSizePolicy::Minimum);
    l->addAnchor(cancelButton, Qt::AnchorRight, l, Qt::AnchorRight);

    // Done!
    scene.addItem(w);

Note, for simplicity the code does not populate the group box with items, since that is easier done with a grid layout. Thus, the anchor layout reduced 4 layouts into one.

There’s a lot of interesting things I could mention here, but I would then be just repeating what’s already written in the documentation, so if you are interested I suggest you take a look at that.

Conclusion

The anchor layout has some attractive properties. For some setups it provides a more intuitive API that is closer to how the UI designer would specify it. It is also very flexible: You can construct free-form graphs of anchors where one edge might be anchored to several other edges. You can modify size policy of each anchor, which means there is little use for a spacer item. You can also modify the spacing to be both a positive and negative value.

Of course, the anchor layout is not the silver bullet and in a lot of cases you are better off with just using a linear or a grid layout. The anchor layout is a flexible layout, and there is a price you have to pay for that: For some arrangements it can be very verbose compared to a linear layout, since you don’t have to anchor each item together (the “anchoring” is implicit by the order of the items).

Read the rest of this entry »

A few weeks ago, we had an awesome insane idea: to translate Qt Creator into French. It turned out to be a terrible idea, because it was much more work than what we originally thought.

We started to translate the strings and it didn’t take us long to realize how huge Creator really is, and the list of strings to translate seemed endless. We ended up asking for help in one of the French Qt communities, Qt.developpez.com. Their response was amazing, they worked like crazy on the translations, and thanks to them, the next version of Qt will provide a French version of the tools. From Qt 4.6.0 on, you will have a French version of Qt Designer and of Qt Assistant. Qt Creator 1.3.0 is available in French entirely, including the integrations and the less known plugins.

The translation of thousands of strings, by non-profesionnals, in only a few weeks, have been quite a challenge :). Thanks to Jonathan Courtois, Alp Mestan, Florent Renault, Pierre Rossi for their amazing work on translations. Thanks to Yoann Lopes for the review of some of the tools.

Thanks to great efforts from the community, Qt Creator has translations for German, Spanish, Italian, Japanese, Polish, Russian, Slovenian and now French. Everybody is welcome to participate in those translations or to create a new translation via the GIT repository on gitorious. If you would like to help the French translation, you are welcome on the forums of developpez.net to meet the other translators.

---

Il y a quelques semaines, nous avons eu une idée géniale stupide : traduire tout Qt Creator en Français. Il s’est avéré que cette idée était ingérable, car cela représente bien plus de travail que ce que nous avions initialement imaginé.Après avoir commencé la traduction, nous avons rapidement réalisé à quel point Creator est immense, et la liste des chaînes à traduire semblait sans fin. Nous avons demandé de l’aide à l’une des communautés Qt francophone: Qt.developpez.com. Leur réponse a été incroyable, ils ont travaillé comme des fous sur les traductions, et grâce à eux, la prochaine version de Qt aura une version francophone des outils. À partir de Qt 4.6.0, une version française de Qt Designer et de Qt Assistant. Qt Creator sera disponible intégralement en Français, y compris les plugins dont personne n’a jamais entendu parler…La traduction de milliers de chaînes de charatères, par des amateurs, en quelques semaines, a été un véritable défi :). Merci à Jonathan Courtois, Alp Mestan, Florent Renault et Pierre Rossi pour leur travail sur les traductions. Merci a Yoann Lopes pour la vérification des traductions des outils.

Grâce aux efforts de la communauté, Qt Creator est traduit en Allemand, Espagnol, Italien, Japonais, Polonais, Russe, Slovène, et maintenant Français. Tout le monde peut aider à ces traductions, ou créer de nouvelles traductions, via le dépôt GIT sur gitorious. Si vous désirez aider la traduction française, vous êtes les bienvenus sur les forums de developpez.net pour rencontrer les autres traducteurs.

As previously described (1, 2), Qt 4.6’s QtScript implementation is based on WebKit’s JavaScript engine, JavaScriptCore (you might’ve also heard it being referred to as “SquirrelFish” or “SquirrelFish Extreme”). This blog is an attempt to highlight the major implications of this “under-the-hood” change.

Looking for bars in all the right places

So, is QtScript any faster in 4.6 than in 4.5? As an indicator, I ran the SunSpider benchmark with both versions. Here are the results obtained on my Linux box (longer bars are better; they show speedup over Qt 4.5, so Qt 4.5 results are all 1): Part 1:

Part 2:

Although these results shouldn’t really be that surprising (boosting performance was one of the key reasons for switching to JavaScriptCore, after all), I can think of two principal ways of interpreting them. One is to say that pre-4.6 QtScript is dog slow, whereas in 4.6 it has good performance (AKA “It’s cat fast”). The other interpretation (my personal favorite) is that pre-4.6, QtScript is sufficient for “scripting in the small/medium”, but with 4.6 it gains the ability to better tackle “scripting in the large”. It’s possible to do more heavy processing on the script side, which effectively means that more use cases for application scripting can be supported.

It’s not always going to be faster.

While 4.6 is practically guaranteed to perform better than previous Qt releases for long-running scripts, that’s not necessarily the case for small, short-running scripts, however. JavaScriptCore’s virtual machine is more complex than the old QtScript VM (it’s register-based rather than stack-based, for example) and currently there’s no hotspotting, i.e. scripts are always JIT-compiled (on the platforms where JIT is supported & enabled). This means that for small scripts, it can take more time to compile the script than to actually execute the compiled form, and the old and relatively simplistic QtScript VM could do it faster. For “1 + 2″, the old VM wins.

In order to mitigate this potential issue in the case where you have a small script that you want to run several times, Qt 4.6 comes with a new class called QScriptProgram. QScriptProgram automatically caches the compiled form of your script. This class was added rather late in the 4.6 development and is marked as internal in the 4.6.0 release, so it won’t show up in the documentation, but it’s there and we think it’s safe to start using it… Here’s how:

QScriptEngine engine;
QScriptProgram program("1 + 2");
qDebug() << engine.evaluate(program).toNumber(); // QtScript lazily compiles and executes the program

...

qDebug() << engine.evaluate(program).toNumber(); // QtScript directly executes the compiled program

We are of course interested in hearing what kind of performance experiences you have with QtScript in 4.6, good or bad.

QtScript, JavaScript… What language is it anyway?

The QtScript language is based on the ECMA-262 standard, which is essentially a subset of JavaScript that was standardized after JavaScript was designed. Prior to Qt 4.6, there were two major issues related to QtScript and ECMA-262 compabilitity. First, QtScript wasn’t 100% compliant (yes, that’s the nuance between “based on” and “strictly adheres to” kicking in), so you as a QtScript script author had to learn and keep in mind where it deviated from the standard.

Second, being 100% compliant to the ECMA-262 standard is not really something to strive for anyway, since it’s not the language people use; JavaScript is the “de-facto” ECMAScript variant that’s actually in use out there. Ideally, then, the QtScript language should be JavaScript. It certainly shouldn’t be something that isn’t quite standards-compliant yet doesn’t quite support real-world JavaScript either, because that severely limits its scope and ease of use.

In addition to the “QtScript is JavaScript, so I only need to learn JavaScript”-argument, turning the QtScript language into “proper” JavaScript has two major benefits. First, there’s a lot of existing and yet-to-be-written JavaScript code that doesn’t strictly require a browser to be useful (libraries for doing “class-based” programming, for example). It would be nice if you could just evaluate those scripts with QtScript and be reasonably confident that they won’t blow up. In 4.6, you can. Second, Qt has this other component called QtWebKit that also does JavaScript. It would be nice if QtScript spoke the exact same language. In 4.6, it does. It’s a good start for a tighter integration between those two components. (Unfortunately, in 4.6 that integration is still not present in terms of actually mixing QtWebKit and QtScript C++ APIs.)

“I used to have behavioral issues, now I’m feeling better”

Prior to 4.6, perhaps the place where QtScript did worst in regard to compliance was how it dealt with Date and RegExp objects. Instead of implementing the semantics defined in ECMA-262, Date and RegExp were essentially wrappers around QDateTime and QRegExp. While this was convenient for us to implement, it meant that you could get some “interesting” behavior compared to that of a more compliant engine. Imagine loading an existing JavaScript library, hundreds or maybe thousands of lines in size, where one of the functions defines this finely tuned regular expression that doesn’t quite do what it should in QtScript because QRegExp semantics are not quite the same as those of JavaScript regular expressions… Fun. Actually, that’s a story from real life. Not so fun.

With 4.6 we get well-behaved Date and RegExp objects “for free” from JavaScriptCore. There are lots of other compliance issues and bugs that are gone too.

Of course, it can’t be all roses and peaches. For example, if you’ve been relying on evaluating nameless function expressions as statements, you should be aware of this quirk that will be present in 4.6.0.

License change

As of Qt 4.6, due to the dependency on JavaScriptCore, the QtScript module is only available under the LGPL or a compatible license. If you want to use QtScript under the commercial license, see one more section down.

Changes in platform support

Platform-wise, JavaScriptCore is a very interesting beast compared to the old “bread-and-butter” QtScript implementation. As you may know, QtWebKit is disabled on some platforms because it plain doesn’t build, or it’s not tested in WebKit upstream, so it could break at any time. Since QtScript depends on JavaScriptCore in 4.6, a subset of WebKit needs to be compiled in order to build QtScript. Unfortunately, that subset is quite needy and picky with regard to the tool chain. Consequently, in 4.6 we don’t guarantee that QtScript-with-JavaScriptCore works on Tier 2 platforms where QtScript of previous Qt releases did. Yeah, it sucks, but we don’t have the resources currently to maintain and test all those platforms and configurations. There haven’t been any reports on this matter for the beta and Release Candidate, but in any case there’s a backup solution:

Introducing QtScript Classic

Can’t live with QtScript gone LGPL? QtScript doesn’t build on your platform? Found an (intentional or unintentional) change in QtScript behavior that affects your application when running against Qt 4.6.0? First of all, if your answer is “Yes” to either of the last two questions, we would greatly appreciate it if you report the problem. Second, we are providing the old QtScript back-end as a separate Qt Solution, called QtScript Classic (follow the link for more information and downloads). QtScript Classic can effectively be used to replace the QtScript from 4.6 with the latest from the 4.5 line. Note that Qt 4.6 can be configured with -no-script to avoid building the standard QtScript module. Again, for Tier 2 platforms, if you experience issues with the 4.6.0 release consider trying QtScript Classic.

Conclusion

In Qt 4.6, QtScript should be faster for computation-heavy scripting. It should be more standards-compliant. The C++ API should still behave the same, unless documented otherwise. In short, existing code should mostly continue to work, only faster than before. Please let us know if that’s not the case. Reported issues will appear on the QtScript component page in the bug tracker.

Introduction

Texas Instruments has a wiki which documents what is required to bring Qt
up on the Beagle board with full OpenGL ES (1/2) support:

http://www.tiexpressdsp.com/index.php/Building_Qt

and I would like to thank one of their engineers, Varun, for his quick turn
around times in addressing any questions I raised.

This blog entry is intended to serve a similar purpose, but is more verbose regarding
Qt considerations and the initial beagle board bring up. It attempts to serve
as a comprehensive independent source of information on getting Qt built
for the Beagle board with full OpenGL ES 2 support.

These instructions are intended for use with Qt 4.6 (and beyond), so grab
the release candidate or check Qt 4.6 out from the public git repository prior
to proceeding.

You can choose to use either Qt/Embedded or Qt/X11, both can
be successfully integrated with the Beagle board’s SGX GPU and the only
point of divergence in these instructions will be at (Qt) configure time
and the client side system (run time) configuration. Both implementations
offer window management, via QWS and X11 respectively, and operate at
around 27fps and 22fps respectively when running our hellogl_es2 example.
(16bit color depth at 1280×720)

I personally deploy Ångström on my Beagle board, it handles a large amount
of the logistics surrounding cross compilation and is generally very
agreeable, and these instructions are therefore going to be bolted to
Ångström for completeness. Feel free to establish an environment capable of
showing the OpenGL ES examples TI provide, then following the Qt level
considerations (Configuring Qt) accordingly.

For those holding a dormant Beagle board who are open to the author’s
distribution preferences:

Building the Ångström rootfs

Open Embedded is manifested in a git repository: in this posting we are
working within origin/stable/2009. Please follow the instructions give
here, they are comprehensive and got me completely off the ground.

http://www.angstrom-distribution.org/building-angstrom

These instructions end in you running:

bitbake base-image ; bitbake console-image ; bitbake x11-image

which actually builds an X11 angstrom image for your Beagle board. Please
note, you will need to build the X11-image if you want to build and deploy
the SGX packages (we will do this in the next section) via Ångström as opkg considers
X11 to be a required dependency of libgles-omap3_3.00.00.09. This is due
to one of the encapsulated windowing system libraries being X11 centric:

libpvrPVR2D_X11WSEGL.so

Regardless of the indicated X11 dependency, this package will bestow the required
kernel module on you for general OpenGL ES usage (console or X11). We will be
building our own QWS centric (libpvrPVR2D_X11WSEGL.so equivalent) library
behind the scenes for QWS in the Qt/Embedded instructions given later.

Ångström SGX integration

You now need to integrate the SGX drivers on your Ångström system.

You need to get your paws on:

OMAP35x_Graphics_SDK_setuplinux_3_00_00_09.bin

with the following MD5 checksum:

e15147ad76ddbe7c5aec682f5455b774

Getting this involves following the above link and going through the required registration/request process.
Once you have this file, you drop it in:

$OETREE/openembedded/recipes/powervr-drivers/libgles-omap3

and then run:

bitbake libgles-omap3-3.00.00.09

which generates the following packages:

libgles-omap3_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-dbg_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-demos_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-dev_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-tests_3.00.00.09-r1.1_armv7a.ipk

Deploy the x11-image to an sd-card, and copy these packages to the sd-card
for deployment on the target. If your beagle board does not have internet
access you will probably also require:

*  devmem2
*  libx11-6 (Only if you insisted on using a console build!)

as opkg will not be able to automatically install the required dependencies
from its repositories and you would hit the following error at deployment:

———————————————-
root@beagleboard:/opt/deploy# opkg install ./libgles-omap3_3.00.00.09-r1.1_armv7 a.ipk
Installing libgles-omap3 (3.00.00.09-r1.1) to root…
libgles-omap3: unsatisfied recommendation for libgles-omap3-tests
Collected errors:
* ERROR: Cannot satisfy the following dependencies for libgles-omap3:
*  devmem2 *  libx11-6 (>= 1.1.5) *
———————————————-

Once you have installed all the above packages, please reboot the board.

Your bootargs in U-Boot should look something like:

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280×720MR-16@60

assuming you want to output via DVI and are running a similar kernel
version (2.6.29-omap1 on my beagle) which accepts the same kernel
arguments indicated in the bootargs variable above.

Please note that we are specifying a 16 bit color depth which is intentional
and discussed in the “color depth considerations” section in the appendix

Please run the powervr demos (under X11) to establish that your drivers are
successfully installed and usable.

Configuring Qt

In order to build Qt now, all that is required for each target is an
appropriate mkspec:

For Qt/X11

You would fork your mkspec off the linux-g++ mkspec, the resulting mkspec’s
qmake.conf would resemble:

==================================================================
………….
include(../common/linux.conf)

# modifications to g++.conf
# These release optimization flags are TI supplied
# and a little more aggressive than Qt standard (gentoo types rejoice!)
QMAKE_CFLAGS_RELEASE     = -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
QMAKE_CXXFLAGS_RELEASE     = $$QMAKE_CFLAGS_RELEASE

QMAKE_CC         = $FULLY_QUALIFIED_COMPILER_PREFIX-gcc
QMAKE_CXX         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK_SHLIB     = $FULLY_QUALIFIED_COMPILER_PREFIX-g++

# modifications to linux.conf
QMAKE_LIBS_EGL         = -lEGL -lIMGegl -lsrv_um
QMAKE_LIBS_OPENGL_QT     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um
QMAKE_LIBS_OPENVG     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um -lOpenVG -lOpenVGU

QMAKE_INCDIR         = $TARGET_STAGING_PATH/usr/include
QMAKE_LIBDIR         = $TARGET_STAGING_PATH/usr/lib

QMAKE_AR         = $FULLY_QUALIFIED_COMPILER_PREFIX-ar cqs
QMAKE_OBJCOPY         = $FULLY_QUALIFIED_COMPILER_PREFIX-objcopy
QMAKE_STRIP         = $FULLY_QUALIFIED_COMPILER_PREFIX-strip

load(qt_config)
==================================================================

and you would configure Qt with:

configure -arch arm -xplatform linux-omap3-g++ -opengl es2 -openvg

all that remains is to adjust /etc/powervr.ini on the target to be:

[default]
WindowSystem=libpvrPVR2D_FLIPWSEGL.so

Now compile an example, eg:

./examples/opengl/hellogl_es2

deploy it and Qt to the target and enjoy.

For Qt/Embedded

Since we don’t have the X11 abstraction, we have to interface with the
underlying hardware/interfaces with Qt/Embedded’s gfx abstraction layer. We
are going to be making some heavy use of the powervr driver resident under:

$QTSRCTREE/src/plugins/gfxdrivers/powervr

there is a README file in the powervr directory that is definitely
recommend reading, and lends some serious insight into our powervr driver
and Qt/Embedded in general. The same driver is used for MBX/SGX targets and
hence sees a fair amount of usage on a variety of target devices.

You would fork your mkspec off the qws/linux-arm-g++ mkspec, the resulting mkspec’s
qmake.conf would resemble:

==================================================================
…………….
include(../../common/qws.conf)

# modifications to g++.conf
QMAKE_CFLAGS_RELEASE     = -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
QMAKE_CXXFLAGS_RELEASE     = $$QMAKE_CFLAGS_RELEASE

QMAKE_CC         = $FULLY_QUALIFIED_COMPILER_PREFIX-gcc
QMAKE_CXX         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK_SHLIB     = $FULLY_QUALIFIED_COMPILER_PREFIX-g++

# modifications to linux.conf
QMAKE_INCDIR         = $TARGET_STAGING_PATH/usr/include
QMAKE_LIBDIR         = $TARGET_STAGING_PATH/usr/lib

QMAKE_LIBS_EGL         = -lEGL -lIMGegl -lsrv_um
QMAKE_LIBS_OPENGL_QT     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um
QMAKE_LIBS_OPENVG     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um -lOpenVG -lOpenVGU

QMAKE_AR         = $FULLY_QUALIFIED_COMPILER_PREFIX-ar cqs
QMAKE_OBJCOPY         = $FULLY_QUALIFIED_COMPILER_PREFIX-objcopy
QMAKE_STRIP         = $FULLY_QUALIFIED_COMPILER_PREFIX-strip

#These defines are documented in the powervr README, please read it
DEFINES += QT_QWS_CLIENTBLIT QT_NO_QWS_CURSOR

load(qt_config)
==================================================================

and you would configure Qt with:

/opt/dev/source/qt-beagle-4.6/configure -embedded arm -little-endian -xplatform qws/linux-omap3-g++ -opengl es2 -openvg -plugin-gfx-powervr

all that remains is to adjust /etc/powervr.ini on the target to be:

[default]
WindowSystem=libpvrQWSWSEGL.so

Now compile an example, eg:

./examples/opengl/hellogl_es2

deploy it and Qt to your board, and after shutting down X, run the example with
the following arguments:

./hellogl_es2 -qws -display powervr

-qws - starts the application as the QWS server with exclusive access to the
system hardware which manages all subsequent Qt “client” applications

-display powervr - indicates that Qt should use the powervr driver we
compiled earlier

Summary

I hope that this posting encourages people to go forward and experiment
with a fully accelerated Qt 4.6 on the beagle board. Offloading the
painting work onto the GPU drastically reduces the load on the CPU and
broadens the range of applications which can feasibly be run on this
broadly available (cheap!) embedded hardware. The Beagle board has
really nice hardware, and it would be infinitely useful for us to have external
people using our powervr driver and getting it as broadly used/refined as
possible.

Appendix

Additional Benefits to OpenGL ES acceleration

If you take any Qt Graphics View based example and set a QGLWidget as its
viewport, a large amount of work will be offloaded on the GPU leaving your
CPU free to frolic. To put this in perspective, a modified version of:

./examples/animation/animatedtiles

which continually transitions runs smoothly at 720p on the beagle board
when using software, but consumes 100% CPU time according to top (99.3% to
be fair). It is therefore CPU bound and you are not going to be doing
anything else in the background.

When backed by a QGLWidget, the CPU usage drops to 20% on the exact same
example in the exact same conditions (720p, at 16bit color depth). The
frame rate suffers slightly, but at least this is mandated by the GPU

Minor clipping issue evident in hellogl_es2

The bubbles are evidently clipped on the right hand side, I will hopefully
beat you to reporting this at: http://bugreports.qt.nokia.com/secure/Dashboard.jspa

I have not seen any other artifacts, please file any additional bugs you
may encounter at the above URL.

Are these instructions applicable to OMAP3 targets in general

Yes. There is no theoretical reason these instructions would not suffice
for any OMAP3 based target, although I have not personally verified them
outside of Beagle board usage. Caveat emptor.

No Scratchbox2 usage when cross compiling

The more astute of your would recognize that I bypassed Scratchbox2 when
configuring Qt/X11 this time around. I payed dearly for it, and this X11
build has no fontconfig, dbus or glib support even though the Ångström
subsystem I am building against has support for all of them. If you want a
full fledged X11 build with decent font support and OpenGL ES support,
please either:

1) Invest your time in physically adjusting your MKSPEC (and/or wrestling
pkg-config) to get all desired dependencies detected and built against

-Or-

2) Take the easy road, refer to my previous blog posting “Cross compiling
Qt/X11″ and merge the above mkspec changes into the:

./mkspecs/unsupported/linux-scratchbox2-g++

mkspec in your Qt 4.6 source tree.

The same goes for Qt/Embedded which is more self sufficient, but which will
be built without dbus, glib, etc and additional external dependency support
without additional mkspec/environment modification or the use of Scratchbox2
to abstract this away.

Color depth considerations

1) The powervr implementation we are relying on does not support
PVRSRV_PIXEL_FORMAT_RGB888 (24bit color depths), it does however support
PVRSRV_PIXEL_FORMAT_RGB565 and PVRSRV_PIXEL_FORMAT_ARGB8888

2) Ångström is busybox based, and the fbset command you will need to set 32
bit color depths on the console will not work with the default fbset
busybox symlink. You will therefore have to install and use fbset(.real)
in order to get 32bit color depths, which is a simple opkg install away for
the connected Beagle board and a bitbake away for the stranded.

Please note the color depth specified in the boot arguments

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280×720MR-16@60

if you want 32 bit color depth, use:

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280×720MR-24@60

followed by:

/usr/sbin/fbset.real -depth 32 -rgba 8/16,8/8,8/0,8/24

after your Linux kernel drops you in userspace with a kiss on the cheek. A
brave man once tried leaving the color depth at 16 in his boot args, and
jumping all the way to 32bit with fbset so he could change between the more
performant 16 bit color space and the hardware compositing ARGB offering.
Running the dedicated fbset command halved his vertical resolution
regardless of any other parameters he tried to pass fbset and he eventually
ran off to fight another day.

There is a clear performance hit of 7 fps when running hellogl_es2 in
32bit rather than 16bit, taking you down to 20 fps. This hit is even more
pronounced when setting a QGLWidget on the viewport of a QGraphicsView. I
am not sure who is responsible for this, and will be personally
investigating it in the future. Any conjecture/feedback/research performed
by the reader would be greatly appreciated.

*Edited: Introduce rudimentary formatting to make the blog look less Vim forged

In the week of November 2nd I travelled to a little village in Italy called Orvieto. The reason for going to this lovely town is two conferences in a row.
The first one is the OpenDocument plugfest. The second is the openOffice.org conference, both of which were new experiences for me.

The ODF plugfest is a meeting where different implementors of a standard come together and come up with user scenarios and test how well they port between the implementations.
So you’ll see a document created in KWord being opened in OpenOffice.org and Microsoft Office and investigations started when the resuls are not as expected.

I did a presentation at the event of the progress made in the Qt (QTextDocumentWriter) and KOffice implementations of ODF and naturally the Maemo Office reader and last mentioned the Nokia sponsored officeshots.org node we are preparing.
The next day I had another presentation where I showed an interoperability issue with right-to-left languages. Several bugs were found in OpenOffice.org and MSOffice and a discussion followed to share the concepts of right-to-left text and (visual) text-alignment. These are tricky things so its important to all have the same ideas on how it should work.

The event had lots of talks, essentially making is clear we are not the only ones doing ODF and showing whats going on in this space. It was interesting to see how far MSOffice has come with ODF, and at the same time how much we need KOffice to become the big second implementor. MS said several times that for optimum interoperability they choose a solution that works better with OOo and not what the specification says it should do. Having a second independent implementation will benefit us all by keeping the standard authoritative, not the most popular implementation.

The event consisted of several interoperability scenarios, essentially manual testing of making a document, saving it in your app and adding it to the wiki. Then loading everyone else’s document and checking whats broken. Followed with an investigation how you can do better. Its a good way to keep the developers focussed so they don’t spent all their time on one feature and being bad overall. KOffice did pretty well here, except for the areas that were already marked as experimental anyway (like change tracking, which is work-in-progress).

Joining the OpenOffice.org conference was making me a bit uneasy, on going there I felt like I’m a spy in the opposite camp. How wrong I could be! The conference was indeed called OpenOffice.org but essentially is a collection of people interested in the open document format as well as the main implementation. There were lots of people from governments and other stakeholders that made clear they were just as interested in KWord as in any other ODF implementation.
This is a stark contrast to the usual events I go to where the majority of participants are volunteers or students. For I went through my business cards quite fast and wished I had brought more.
As usual I get a lot of good energy from these conferences, so many friendly faces, good talks and this being Italy, I had quite good food too

I’m always happy to get a face to a name I’ve been emailing with and nothing works better than a conference in a country where wine is as cheap as water during dinner.

For all you 3D and graphics hackers out there this will not be news:  writing OpenGL code is a pain.

Well, the Qt Graphics team is coming to save your sanity with the a new project called Qt/3D.

We teased about Qt/3D by putting a few of the foundations for it in Qt 4.6, which will be released very shortly. See the Qt/3D 4.6 features blog post for more details.

At some point Qt/3D will be available as part of Qt itself - exactly what sort of module or library we are not sure just yet - but for now you can try it out via Qt Labs!

With this post we’re pleased to announce that Qt/3D will be available for experimental use via the new Qt/3D labs repo.

Old School OpenGL code gets the Qt Treatment

The trusty old QGLWidget got you past first base: a nice window set up with a OpenGL context ready to go.

But from there you’re on your own with the OpenGL reference book, tearing your hair out writing code like

void My3DWidget::paintGL()
{
   QColor clearColor(palette().color(backgroundRole()));
   glClearColor(clearColor.redF(), clearColor.greenF(), clearColor.blueF(), clearColor.alphaF());
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   QColor color(170, 202, 0, 255);
   glColor4f(color.redF(), color.greenF(), color.blueF(), color.alphaF());
   static float vertices[] = {
      60.0f,  10.0f,  0.0f,
      110.0f, 110.0f, 0.0f,
      10.0f,  110.0f, 0.0f
   };
   glVertexPointer(3, GL_FLOAT, 0, vertices);
   glEnableClientState(GL_VERTEX_ARRAY);
   glDrawArrays(GL_TRIANGLES, 0, 3);
   glDisableClientState(GL_VERTEX_ARRAY);
}

just to paint a triangle on the screen.

But then if you want cross-platform code - something that you can try on your desktop, and then run on your device with OpenGL ES, it starts to look really horrible!

Macros everywhere to cope with the different function signatures and data types - not to mention shaders under ES 2.0 versus classic GL on the desktop, and a swath of other cross-platform difficulties.

With Qt/3D your code looks like this:

void My3DWidget::paintGL()
{
    QGLPainter painter(this);
    painter.setClearColor(palette().color(backgroundRole()));
    painter.clear();
    painter.setStandardEffect(QGL::FlatColor);
    painter.setColor(QColor(170, 202, 0, 255));
    QGLVertexArray vertices(QGL::Position, 3);
    vertices.append(60.0f,  10.0f,  0.0f);
    vertices.append(110.0f, 110.0f, 0.0f);
    vertices.append(10.0f,  110.0f, 0.0f);
    painter.setVertexArray(vertices);
    painter.draw(QGL::Triangles, 3);
}

And what’s more it runs the same on your OpenGL/ES device and your desktop.  (Note that I have elided the view and model transform setup code from both examples above for the sake of space).

As mentioned in the previous blog post Qt/3D has been in the wings for some time now, and the eagle-eyed might have notice math classes springing up in Qt’s GUI module.

These classes provide the basis for Qt/3D’s cross platform geometry abstraction: QGLVertexArray. This nifty class also dovetails into the QGLBuffer class to take care of uploading your geometry to VBO’s on the graphics adaptor, as well as coping with differences in platform on data member sizes.

Download the code from the labs repo and try out the examples - the code above comes from the tutorials directory, where you can find out more about writing your traditional OpenGL apps in the Qt cross-platform way.

Whats in Store with Qt/3D

There’s more to come from Qt/3D over and above the Portability tools mentioned in the example above.

With Enablers are included encapsulation classes like QGLMaterialParameters to encapsulate OpenGL materials in a cross platform and Qt’ish way.

One of the nicest enablers is the QGLView class and its friends.  Doing your GL painting into a view looks pretty much exactly the same as with an OpenGL widget, but a few more things are taken care of for you - no need to set up tricky viewing and model transforms (which is one reason why I elided them from the code above).  But even better as a bonus you get a pan-rotate-zoom view window for free.   Its customizable using the QGLCamera class, and with QGLLightParameters you can quickly set up your own lights too.

Then there’s Real 3D bringing basic but powerful geometry management, and model file import functionality. With this stuff we’re just dipping our toes into the world of 3D to allow coding up of basic applications using Qt style containers, QObject based memory management, and the kinds of abstractions you’ve come to expect from Qt. If you’re an Ogre programmer, or used to using Coin3D or CrystalSpace or other powerful 3D and modelling libraries - well, you’ll still need them. We’re not planning to go into competition with those established 3D toolkits.

Instead our aim is to deliver on the promise of Qt: do more with less.  It should be just as easy to use a 3D model file as it is to use a PNG file, and it should be just as easy to set up a cube with a texture on it as it is to create a Qt label. We call this component of Qt/3D Real 3D because it does start to provide functionality we’re used to seeing in 3D toolkits. But we’re working to be sure we do not go too far to go down this road, and thus to decide what will go in and what will left out - so please consider the stuff in our labs release as definite maybes.

QML and Qt/3D

There’s a lot of buzz around Declarative UI and its associated language QML.

Qt/3D will work with Declarative UI by providing QML bindings so 3D functionality can be easily used from Declarative UI programs. There’s a few demos of this in the source tree which can be tried out and you can see Henriks short video about QML and Qt/3D.

We’ll expand on the exciting possibilities of QML and Qt/3D in later posts.

We hope you like what we’re planning, and look forward to your feedback - keep tuned as there are more blog posts to follow, with some cool examples and things to try with Qt/3D.

Today we present to you what we consider to be a candidate for the release of Qt Creator 1.3.0.

In the month since we released the beta version, we were busy taking your feedback (thanks for that!) and transforming it into code . As a result of that many parts have seen improvements, for example there were issues with the Qt for Symbian support mended (e.g. support for S60 3rd Ed. FP1), several fixes for the refactoring engine done, and debugging improved.

This is a candidate, and we would like to hear of any issues you still find with it. We expect the final release before the end of the year, so now is the time to go to the public Qt Bug Tracker, and tell us.

You can download the packages from the Qt Creator Preview Website.

Today, we move another step closer to the Qt 4.6.0 release, with the shipping of the first release candidate.

This release improves on 4.6.0 Beta 1 by adding yet more bug fixes and documentation improvements, fine-tuning a couple of the new API’s, and incorporating various feedback from you, Qt’s community of developers and users.

The Release Candidate is very close to what the final 4.6.0 release will be. The main aim of the RC is to solicit feedback from the community and catch any remaining high priority bugs before the final release, which we expect will happen before the end of the year.

If you find a bug, we want to hear about it. You can submit a bug report and/or an autotest that demonstrates the bug via the public Qt Bug Tracker. If you know how to fix the bug, you can submit a merge-request to the public Qt source repository on http://qt.gitorious.org.

The Release Candidate is available as a source package (choose from .tar.gz and .zip versions), and as pre-built binary packages for Windows, Mac OSX (Carbon and Cocoa) and Symbian. In addition to the set of binary packages shipped with the Beta, we are now providing an opensource version of the Visual Studio 2008 binary package.

You can get all of the packages from the Qt Preview Website, or from our http://get.qt.nokia.com. You can also find the latest documentation at http://qt.nokia.com/doc/4.6-snapshot/index.html.

Finally, a note for users of the MinGW binary package: This package is now based on MinGW 4.4. The installer no longer offers to download MinGW for you, but rather offers to use a version of MinGW that you already have installed on your machine. You just tell the installer which directory MinGW is installed in.

If you don’t already have MinGW 4.4 installed, you can download a .zip archive from our ftp site. This archive provides fixes to MinGW and support for missing API, See the _patches directory in the archive for details.

I just wanted to post a quick thank you to everybody who congratulated me on the German Medal of Merit, I truly appreciated it.

To get the facts straight: the Medal of Merit is the lowest class of the Order of Merit of the Federal Republic of Germany, unofficially but commonly described as Federal Cross of Merit. The medal does indeed feature a big cross, so the familiar name fits well. In order to get the next class - the Cross of Merit - you will typically have to be at least 40 years old, so this is a good as it gets and it does feel very satisfying indeed.

Let me explain the satisfying part: In Germany, the medal of merit is a state decoration which you receive for merits for the common welfare. It’s granted and signed by the President of Germany, at present Horst Köhler, In other words, this is yet another sign that we, the free software community, the hackers, the geeks, have arrived at what’s called the middle of society. What a change from the beginnings of KDE!

For those that do not rememember, it has taken a long time for free software to be seen as valuable outside our closed circle of hackers. Initially it was even seen as something bad, as some evil movement to harm companies and to kill jobs. When I started with free software I met either indifference, or more frequently malice and total lack of understanding. How can anybody in their right mind waste valuable time with this? For example, I do remember a situation where a fellow student of mine wanted to help me out when he learned that I spent all nights programming a document processor. His solution, in all honesty and seriousness, was to offer me a pirated copy of a commercial word processor.

And now this. Official recognition by the President of Germany. Should anybody wonder why you spend time with free software, let them know that in Germany this is officially recognized as work for the common welfare - isn’t that plain brilliant?

Obviously it’s not the freedom aspect per se that makes our software relevant for the common welfare. A free ego-shooter, while fun to work on, might for example not fall into this category. What makes all the difference is what we strive to achieve with KDE - and with the free desktop in general: a complete system for normal users, everything you need to participate in our modern communication society.

Society in Germany is starting to recognise this value. So I have been lucky enough to be selected as a representative for you all. All of you that strive to broaden the use of free software for everybody. It was both a day for me to proudly look back on what I have achieved with you, and for all of us as a community to be proud of what we achieve together. Whether you are a direct contributor, a supporter or a user of free software, be it KDE, Gnome or the underlying distributions, this award was just as much for you. I hope you are as proud as I am. You should be.

Thanks again, and keep on hacking.

To everyone using Qt 4.6 from the Git repository: be aware that I introduced a binary-incompatible change. This change is there to stay.

No, we’re not breaking binary compatibility with Qt 4.5. This only affects previous Qt 4.6 versions.

Actually, this kind of change happens all the time. So why am I blogging about this specific change?

Well, the problem is that this change affects QHash, QMap and QVector. And those classes are inlined everywhere in Qt-using code. This means that, if you update Qt across that version, you must recompile all of the Qt-using code, from scratch (i.e., make clean). For KDE developers using trunk, that means recompiling all of KDE.

This change will be included in the upcoming Qt 4.6.0 Release Candidate.

Note: the change is in the 4.6 branch but hasn’t reached the 4.6-stable branch yet. That also means it’s not in kde-qt’s 4.6-stable-patched branch yet. When you next update those stable branches, please remember to recompile everything.

PS: the stable branches aren’t updating not because of Qt not building. It is buiding. The reason why is because our Continuous Integration system experiencing some technical difficulties, like Windows running out of memory, the Symbian buildsystem failing for no apparent reason, the powerful 8-core Mac machines being able to run only one testcase at a time, etc.