Have you ever had the wish to connect your Laptop or mobile device to the Internet with the help of Qt (in particular in public environments such as airports or the local shopping center )? Well, the Bearer Management API is exactly what you are looking for

The ability to utilize a large variety of sometimes transient networks is an important feature for any mobile platform such as mobile phones or laptops. The user wants to be online for as long as possible while at the same time cost and speed are optimized for the use case at hand. The Bearer Management API provides important enablers such as the basic ability to start, stop and monitor network access points, access point grouping and roaming capabilities (the process of migrating from one network to the next) and session management. In addition mobile specific functionality such as the discovery of transient and stationary access points (e.g. Ethernet, WLAN or GPRS/3G) is supported.

What other features does this API bring to Qt? Apart from the use cases mentioned above other indirect use cases become possible. For example QNetworkAccessManager based applications (such as Webkit) may simply be able to access the Internet without having to consider whether the device is online already or which access point they should use. HTTP requests could automatically trigger the start of the best (cheapest/fastest etc.) access point and the system would ensure that a network interface does not shutdown until the last user has indicated that the interface is no longer required (session management).

One of the most challenging aspects of this API is the large, and sometimes opposing, variety of system capabilities. Symbian/S60 provides almost all desirable aspects for mobile networking whereas desktop platforms (due to their rather stationary context) are pretty limited. Laptops are usually somewhere in the middle of the feature scale. One of the most obvious desktop issues are missing (public) API’s which could give access to the required feature set and session management. This diversity is reflected by some API elements whose only purpose it is to detect the platform’s capabilities. The most minimalistic feature set supported by all platforms is the ability to asynchronously monitor network interfaces. This is implemented by using busy polling via QNetworkInterface. Where possible more specific platform API’s are used to extend the feature set and avoid polling. The most complete feature set is provided for Symbian/S60 version 3.1 or higher and is based on RConnection.

The current API supports Symbian/S60 3.1+, Windows, Linux (NetworkManager) and a generic QNetworkInterface fallback backend. More platforms are planned. Note that the recently released Qt/S60 Tower pre-release and in particular the updated version of OpenC is required to enable roaming for S60 devices.

The code is available on Gitorious and please feel free to send your comments/feedback to qtmobility at trolltech.com.

If you use QWebView, do you know how make its background to be translucent? Apparently, the trick is not so well known, hence I decide to share it here.

Basically it boils down the following code snippet:

QPalette palette = view->palette();
palette.setBrush(QPalette::Base, Qt::transparent);
view->page()->setPalette(palette);
view->setAttribute(Qt::WA_OpaquePaintEvent, false);

The first three lines set a new transparent brush for the page. This is necessary so that all the painting is blended properly. The last one ensures that the web view is not opaque, i.e. it does not paint all the pixels contained in its rectangle. Opaque paint event for QWebView is the default, most of the time you want to have a web page with typical normal background color, either set by the web page or something you specify as the fallback color.

If you combine QWebView see-through background with top-level widget opacity feature (see what Samuel wrote about this some time ago), you will get something like the following screenshot (the wallpaper image is Soft Green, from Valient Gough). Neat, isn’t it? Note that of course it requires a window system which supports composition, e.g. modern X11 window manager, recent versions of Windows, and so on.

As usual, the code for this short example is available from the git repository, just check the transparentweb subdirectory. Again, I already prepared both the Qt/C++ and Python (via PyQt) versions. Enjoy!

In the recent pre-release of Qt for S60 we have included a build of WebKit that compiles and runs on S60. This pre-release is an important milestone for this porting effort that started about half a year ago. Hence, I would like to briefly highlight a few things about it:

The main work is finding good solutions for quirks in the toolchain. That includes the ARM RVCT compiler and the Metrowerks compiler used by the emulator on Windows, both with their own unique set of challenges.

The team working on this consists of Norbert Leser and Laszlo Gombos from the Nokia Browser Team in Boston as well as Janne Koskinen from Digia and Kristian Amlie from the QtSoftware Team here in Oslo. In addition Ariya wrote the little but super-cool anomaly demo browser, which is included in the Qt/S60 Tower release. The port is still in early stages, but it’s looking quite good already and rather performant.

We’ve been maintaining the patches in separate repositories and we’ve been pushing patches in small steps upstream for a few months now. There’s still a lot to go, but things are progressing. And the result is looking really cool

I did some work this week on a task related to higher DPI values on Vista. The task was essentially about scaling artifacts related to checkboxes, radio buttons and menus. However after fixing up those I decided that we needed a little more to really work properly on Vista and Windows 7 and realized that there were still quite a few hard-coded pixel metrics in the current styling API that really should depend on DPI as well. So after adjusting those metrics, most Qt apps should now look a lot nicer at higher DPI values. The fixes will also directly benefit similar functionality on Mac, once this gets properly supported by Apple.

Here are some screenshots showing noticable improvements in 4.6 vs 4.5 at a moderate scale size of 1.25:

With the improved DPI-scaled metrics this is what it should look like in 4.6:

No radical change in this case, but it certainly looks more polished than the old one. At very high DPI scaling values (1.5 and up) Windows Vista defaults to showing applications in a compatibility friendly, but rather fuzzy scaled mode. In 4.6 we plan to make applications scale properly by default. Unfortunately existing applications are likely to have pixel-based assumptions, so the only real way to ensure that your app will look correct is to try it out.

And again, this is how things should look with 4.6:

After three incredibly short months, the Qt to S60 porting team is pleased to provide another pre-release of the port! This time, the pre-release code name is “Tower”. Nearly all functional areas which are wrapped by Qt’s beautiful Api are now doing their job also on S60.

Red carpet
The red carpet to S60 development with Qt is now rolled out for You. Despite some tiny roughness here and there, Your walk over that carpet should be safe and pleasant. In other words: If You did not already, this is the perfect time to start playing with Qt for S60

What’s new?
Besides the usual optimizations, fixes, code cleaning and various improvements, there are three fresh modules: Phonon, QtSql and QtWebkit, new softkeys and input methods APIs, as well as a brand new installer.
Phonon on S60 is building and applications that are built against it will run, but there is currently no functional Phonon backend on S60. QtWebkit on S60 is still considered experimental. However, You should already be able to start developing QtWebKit refined applications for the pocket. A complete list of changes can be found here.

In addition to the new features, work has also begun on making Qt exception safe, in order to fill the gap between Symbian and Qt exception systems. You can read more about Qt and exceptions here.

Installation is easy!
This release makes the installation of Qt for S60 easy. An installer will copy the Qt libraries (for emulator and hardware) to the places where they belong. Start using Qt, right away, the dark ages of required manual Qt builds are over.

Getting started
We at QtSoftware love to create videos. This time, we have three of them showing some demos and how to get started:

Qt for S60 is getting close to being feature complete, and is also much easier to install than before. We really think that this release makes it worth walking the red carpet!

When I started more than two years ago at the Berlin office (then called Trolltech GmbH), Creator was a Creative Friday project called Workbench. Later it got renamed to Project Greenhouse; shortly before the first release we settled for the name Creator. Though I did think that Greenhouse had a nice touch, Creator fits perfectly, since it puts you, the Creator of great things in the center. Our philosophy is to not solely focus on a big feature list, but also on small details which make your life easier.

But everyone wants to hear about new features, so here we go:
Our biggest new feature for 1.2 is surely the cdb integration, that is you can now debug applications built with the Microsoft Visual Studio compiler. Also, our debugger dumpers display Qt types in a much nicer way than Visual Studio. See the recent blog post: Peek and Poke.
In the code editor we’ve refined the matching parentheses highlighting and added better code folding visuals and block highlighting. The block highlighting feature illustrates the size of each block using different shades of gray for the background. For me, it’s unobtrusive highlighting of scopes is a nice touch. However, this feature is optional and can be turned off.
Another cool new feature is the automatic updating of the code model when the .ui file changes. In other words, you can drop a widget on the form and immediately enjoy code completion even without saving. Finally, when you start Creator 1.2, you’ll be greeted by our new welcome screen.

To mention a few of the small features we implemented to make your life easier:

• Search and replace with regular expressions
• Better faking of vim
• Auto Save before Build, Run without Building Options
• Ability to disable breakpoints
• Better auto detection of installed VS compilers
• Tons of stuff

Edit: You can download the Creator 1.2 release and the 2009.3 SDK, which consists of a prebuild Qt and Creator 1.2 from here.

Qt developers in Oslo, Berlin, Brisbane and other assorted locations are proud to announce that Qt 4.5.2 is now available.

Qt 4.5.2 is a patch level release providing bug fixes and performance improvements over the 4.5.1 release that went out in April. You can get Qt 4.5.2 here and you can see what’s changed in the changes log.

This release is a significant milestone in Qt’s life. It is the first release since the Qt development repository was made public and is thus the first release to include code directly contributed by members of the open-source community. Contributions from the community have already improved the quality of several of Qt’s component’s for this release. We are grateful for the hard work and generosity of those who have contributed patches, bug reports and autotests, and we look forward to our relationship with the developer community growing stronger with each Qt release.

If you too would like to get involved in shaping Qt’s future, everything you need to get started can be found at qt.gitorious.org.

Recently we’ve been working on writing an OpenVG graphics system for Qt 4.6, and now it is all ready to go!

Qt 4.5 added support for pluggable graphics systems, which allow the window drawing surfaces and their associated paint engines to be redirected to a plugin for handling.  There are graphics systems for OpenGL 1.x and 2.x, and now for OpenVG!

The new graphics system supports OpenVG 1.0 and 1.1, and uses the Khronos EGL API’s to access VG contexts and low-level window surfaces.  It directly converts QPaintEngine requests into the equivalent OpenVG requests - the two API’s are very similar in functionality, so it was relatively easy to do this.  It has been tested using X11/EGL and S60.  There is also a demonstration plugin that uses ShivaVG, which shows how to use a non-EGL VG implementation.

What’s supported?

• Single-context vs multi-context - the default configuration uses a single VG context and multiple window surfaces.  This improves performance by sharing VG paths, images, and paint objects. But you can switch it to one VG context per window if your engine requires that behaviour.
• All Qt transformations are supported, both affine and projective.  However projective path transformations need to be done client-side, so they won’t perform as well as affine transformations.  Images support both affine and projective path transformations server-side.
• Pen and brush styles except conical gradients, which don’t have a VG equivalent.  Opacity is supported for all drawing operations.
• All the usual Qt primitives: lines, rectangles, points, polygons, ellipses, etc.  For rectangles and other simple objects, path objects are reused to reduce the overhead of recreating them every time.
• Clipping uses both masking and scissoring, or just scissoring if your engine doesn’t support masking. Scissoring will generally be preferred for simple rectangular clipping.
• Text drawing is very dependent upon the features in your VG engine. For OpenVG 1.0 it uses the default vector path rendering in Qt, which may not give the best result.  For OpenVG 1.1 systems that support VGfont objects, you have a choice of image-based or path-based glyph uploading.  Image-based glyphs are the default.
• Pixmaps are represented as VGImage objects (in single-context mode only) and so they can be drawn and transformed very quickly. The pixmap filters from Qt 4.5 (convolution, drop shadow, and colorize) are supported using VG functions.

What’s left to do?

• Testing, testing, testing!  Every VG engine has its subtle quirks so help us narrow them down.
• Rendering into a QPixmap using VG - at present it drops back to the raster paint engine.
• Text drawing with image glyphs under OpenVG 1.0.
• Qt/Embedded support - some experimental screen drivers have been written internally but every vendor’s EGL is different, which makes Qt/Embedded difficult to support for both OpenVG and OpenGL/ES.

Where to get it?

You can get the engine from the public Qt repository.  To build it, you’ll need to edit your mkspecs to specify the include directories and libraries to link against for EGL and OpenVG.  And then configure Qt with the “-openvg” option.  Once it has built, use “app -graphicssystem OpenVG” to run an app using the graphics system plugin (or “app -graphicssystem shivavg” for the ShivaVG version).

Not long after Brad blogged about multi-touch in May, I got my hands on a brand new MacBook Pro under the excuse of implementing multi-touch support for Qt on Mac. This machine has a big and sexy trackpad (excuse my sexual orientation) that goes beyond normal mouse control to also include multi-touch- and gesture support.

After jumping on to the implementation, my first thought was that this was going to be a fairly quick thing to do. The API from Apple is rather straight forward. But after a short while, we started to realize that a touchpad (or trackpad in the case of a Mac) is more different from a touch screen than originally anticipated. The main difference being that on a touch screen, you place your finger directly on the widget you want to interact with. Qt then identifies that widget as the receiver of any following touch events. With a touchpad, you cannot place your finger directly on any widget in a similar fashion. You need to move the mouse to the widget first using the touchpad. This means that your first touch (and all following touches) will go to the widget under the cursor when the move starts, and not to the widget you are navigating to. So you would then need to do an extra step of lifting all your fingers and put them back-on the pad once the cursor is over the correct widget. In practice, this feels wrong and unintuitive.

After some hallway discussions and try-outs, we found that which widget to send touch events to should be decided after the second finger has been pressed. This is almost the same as saying that you will only get touch events when you are not controlling the mouse. This will normally be enough for applications that uses multi-touch for implementing gestures. If you are implementing single touch gestures, or otherwise need to handle the first touch, we added a flag you can set to override this default behavior. On a touch screen, you will always get all touch events.

A second problem regarding single touch (on a touchpad only) is the process of mapping touchpad position to screen position. When the touch begins, it is easy: screen position should be where the mouse is. But then it gets more blurry. The mouse will now move on the screen with a user defined speed and acceleration. So when your finger moves two centimeters on the touchpad, the mouse might move ten centimeters on the screen. In that case, should the screen position of the touch move with two centimeters? Or should the touch follow the mouse? The user would normally expect the latter (since there exist a logical connection between the touchpad and the mouse), especially if there are no visual clues on screen to mark the touch. However, implementing a strategy like this will grow in complexity (and inconsistency) once you start moving more fingers on the touchpad. And besides, recognizing gestures with mouse acceleration applied is not for the faint of heart. Conclusion: a touch will move on screen 1:1 with the touchpad. If you need to know where the mouse is, use mouse events.

In some cases, it might be more useful to know where the fingers are on the touchpad, rather than on the screen. To accommodate for this, we added to the touch events what is called a normalized position. This position range from zero to one, with the upper left corner of the touchpad being (0, 0), and lower right being (1, 1). With this information you can implement your own screen mapping, if you like.

Finally, there are certain limitations for using multi-touch. The API available from Apple is only for Cocoa, and only for Mac OS 10.6 (Snow Leopard). As a result, multi-touch for Qt/Mac will only be available for the Cocoa port running on OS 10.6. On the upshot, gestures are supported starting with OS 10.5.2, both in Carbon and Cocoa. Qt will of course mirror the same support.

Remember the days when all the tools at hand looked like a Basic interpreter with 30 commands, the most usable being PEEK, POKE and PRINT? Yes, that’s been a while…

Nevertheless, a few months ago I found myself doing lots of “printf-style debugging” again. Even with some basic IDE support that nicely displays QString and QByteArray, digging into more complex structures was just no fun. One of the reasons was certainly that we humans like to think of a QHash at a “higher level” of abstraction, in a way that’s fairly different from the actual implementation - and it’s only the low level implementation a debugger usually sees.

One solution is to bridge the gap between the low level (pointers, anonymous unions, …) and the high level (a bunch of keys with associated values) externally. This is done by asking the debugger for the type of an object only, and then - instead of asking for the low level data - tell it what part of the application’s memory is a hash key and what part is the corresponding value. This information is then transfered to Qt Creator’s “Locals & Watchers” view.

Below is the result for some nested containers and two QObjects with a parent-child relationship:

In the latter case the “more traditional” approach of displaying low-level data would produce:

The low-level display of a QHash is even less impressive. Of course, Qt Creator can easily toggle between the views, but it’s rarely needed.

For the convenience of the less Qt-centric audience similar displays have been added for a few widely used containers from the C++ Standard Library, proof coming here:

The display of aforementioned types (and a few more) works already with the Creator 1.1 release from April on Linux, Windows and Mac. All that’s needed is a not-too-old version of the GNU debugger. Gdb version 6.8 is just fine and widely available, on Mac Apple’s gdb will do.

As time goes on work continues, too. Qt Creator 1.2 will be able to show QAbstractItem, QAbstractItemModel, QByteArray, QDateTime, QDir, QFile, QFileInfo, QHash, QImage, QImageData, QLinkedList, QList, QLocale, QMap, QModelIndex, QMultiMap, QObject, QSet, QSharedPointer, QString, QStringList, QTextCodec, QVariant, QVector, QWeakPointer, std::list, std::map, std::set, std::string, std::vector, std::wstring as well as a few helper types (QMapData and the like). If you miss something desperately, just tell me

Last but not least, some special news for the people on the Windows side of the world: Starting with Creator 1.2 the debugger frontend will also support Microsoft’s debugger, even featuring the same friendly display of complex data.

André