meta-kf5 usable

Finally I’ve had the time to work over the final issues in meta-kf5. Right now, I build most tier 1 and tier 2 components. I’ve packaged most functional modules and integration modules from these tiers.

When it comes to integration modules, there might be missing dependencies that need to be added – but that should not be too hard to add.

To be able to create useable cmake files, I had to employ a small hack modifying the cmake-files from KF5 before installing and packaging them. This seems to work (i.e. tier 2 builds), but there might be other sed-expressions that are needed.

Also, the autotests are not built as long at Qt5Test is left out form the build. If you would add Qt5Test, I believe that the unit tests will be included in the same package as the libs. I’ll address this as I integrate the autotests into ptest.

Summing up all of this, I’d say that the meta-kf5 layer now is usable!

That is all for now. As always, contributions are welcome! If you find a use for this, I’d be happy to add your project as a reference to the layer!

User Attention and Duration of Engagement in Public Kiosks

Common user experience (UX) wisdom says that you have a short period of time (approximately 3 seconds to 3 minutes) to attract, seduce and convince a user to use your app, site or device. Once you capture their attention, you need to sustain a long-term relationship by offering the user real value (Skype), enduring enjoyment (Candy Crush) or at the very least, an obligation to be a participant in popular experiences (Facebook). Do the same principles apply to public kiosks, such as ticketing, retail and museum kiosks? The answer is yes and no.

Google Labs VoltAir Game Built with Qt


As the dog days of summer carry on, we at Digia, Qt are swatting down flies, mosquitoes and bees while we fan ourselves in the unusual summer heat currently striking Scandinavia … in Oslo … at least.

Meanwhile, on a cool note, the Fun Propulsion Labs at Google announced last week that, VoltAir a single and multi-player game built with Qt is available for download via the Google Play Store and as open source software. Coolbeans!

VoltAir was developed to provide an example of a C++ game designed for both Android and Android TV and the folks at Google also tested it on Nexus 5, Nexus 7, Moto X by Motorola, Android TV, and some Samsung devices.

Check Out VoltAir (Courtesy of Google Developers – YouTube)

 

Google’s Fun Propulsion Labs VoltAir Project page said:

“We looked at various UI frameworks and game engines and decided Qt was not only the more daring choice due to the lack of games developed in it, but also a very interesting one due to the future ability to extend it into a rich editor, support from Digia, and many technical development advantages such as:

  • Provided a platform abstraction that allowed us to also develop and test on desktop, reducing iteration time
  • Included a scene graph and out of the box “serialization” mechanism
  • Allowed for easily building a fluid UI system that was good for games
  • Provided an object model with dynamic JavaScript bindings, properties, as well as callback mechanisms for easy scripting and prototyping
  • Contained a well integrated IDE (QtCreator)
  • Included a flexible LGPL License.”

 

To top it off, our friends at Google gave some more kudos to Qt Quick:

“Qt Quick’s strongest feature by far is its abstraction for building user interfaces. It is, in fact, very well suited for the types of UIs you would expect in a game, where there is a lot of latitude taken in the UI element design and animations are abundant.”

Thanks, amigos from Fun Propulsion Labs Google. We appreciate the kind words and we wish much success to VoltAir.

Go on everybody – learn more about the VoltAir Project and find out why, how they developed the game. Download it now from the Google Play Store or play around with it yourself with the open source code.

meta-kf5 – almost there…

So, as of tonight, all but three tier 1 modules from kf5 are built in meta-kf5. The ones remaining are KApiDox, which does not really apply, and KConfig and Sonnet, which both needs to be part built for the native host environment, and part cross compiled. So, any Yocto hackers out there, please have a look at the issues linked to from the meta-kf5 status page.

meta-kf5 progress report

The meta-kf5 Yocto  layer is coming along nicely. Most of the modules are proving to be fairly easy to integrate, much thanks to the excellent ground work in meta-qt5, including the cmake_qt5 bbclass.

My plan for the summer vacation was to do one module a day, so around 5 would be ok. Until now I’ve done 9. Only KConfig has been providing any resistance (it does not like QT_NO_SESSIONMANAGER). My current pipe for tier 1 modules has 6 more candidates in it, so hopefully I can say that I’ve done 15 modules tomorrow night.

Right now, I have only one big worry – I have no code using the packages, so it is a bit of a if-it-compiles-it-works mentality right now. This should be fixed by integrating the test cases from the KF5 modules with ptest and building a test image. This is something that I’ll have to look at further along the road.

Code highlighting in SlideViewer

A couple of months ago, Jesper Pedersen introduced our presentation tool for trainings, called SlideViewer. As SlideViewer is mainly used for our Qt and Squish trainings, we naturally have many code examples on the slides, ranging from C++ and QML to Python and XML. In this blog post, we will take a closer look at how we use WebKit to power the syntax highlighting of these code examples in the training slides.

In the spirit of not re-inventing the wheel, we looked at existing solutions ranging from the Qt Creator highlighting to what is used on the web. Eventually, we decided upon using the JavaScript based highlighting application SHJS, as that turned out to have the most extensive highlighting out-of-the-box among the solutions we looked at.

The SHJS highlighter does not have a function that you call with a piece of code and get a highlighted version back. Instead, when told to, it traverses the DOM tree of a web page. When it finds a piece of code to highlight, it modifies the DOM tree and inserts <span> elements around the different code fragments. Combining these <span> elements with a stylesheet, we get the desired highlighting of the code.

Of course, in order to provide SHJS with the DOM tree so it can perform the highlighting, we need a web page. The natural solution for that, since we’re in Qt land, is to simply use QWebView and friends. And as we do not need any of the QWidget attributes, our starting point is QWebPage.

To make this work for our code slides, we have a number of steps to take:

  1. Create a web page
  2. Feed the HTML with the code to highlight into the web page
  3. Run SHJS’s highlighting function
  4. Parse the HTML code once SHJS is done

Let’s look at these, step-by-step.

Creating a QWebPage is easy:

m_webPage = new QWebPage(this);

SHJS is modular in its implementation, so for the web page containing the code we want to highlight, we only need to use e.g. the C++ specific parts of SHJS. Looking at the code below, we include both the main script as well as a language-specific script from SHJS, then we wrap our, in this case, C++ code in a <pre class="sh_cpp">...</pre> tag. This tells SHJS that what we want to highlight is C++ code. If we wanted to highlight Python code instead, we would include the “sh_python.js” script and wrap the code in <pre class="sh_python">...</pre> instead.

const QString preHighlightHtml = QStringLiteral("<html>"
                        "<head>"
                        "<script src=\"qrc:///highlight/sh_main.js\"></script>"
                        "<script src=\"qrc:///highlight/sh_cpp.js\"></script>"
                        "</head>"
                        "<body onLoad=\"sh_highlightDocument();\">"
                        "<pre class=\"sh_cpp\">"
                        "%1" // code
                        "</pre></body></html>").arg(code.toHtmlEscaped());

m_webPage->currentFrame()->setHtml(preHighlightHtml);

The code above also takes care of the third item on our list. Notice the onLoad attribute of the <body> tag, telling SHJS to run the highlighting once the page is finished loading.

Now, in order to be notified when the highlighting is completed, we cannot use the loadFinished() signal from neither QWebPage nor QWebFrame. That signal is emitted when the page is done loading, and hence before the highlighting is completed. Remember the highlighting doesn’t run until the page is done loading.

To realize when the highlighting is done, we have a number of options. We could add a timer that checks every 100 ms or so, whether we have any <span> tags present. This might lead to a race though, as some parts of the code might have been highlighted by then, but not all of it.

Thanks to the JavaScript integration, we can make our C++ objects available to the JavaScript context in our web page, and this is the technique we use to get notified when the highlighting is done. So to get notified, we add a callback for the SHJS script to call once the highlighting is completed. This is done by calling QWebFrame::addToJavaScriptWindowObject(..), which makes a C++ QObject available to the frame’s JavaScript context, in this case under the name highlighter.

m_webPage->currentFrame()->addToJavaScriptWindowObject("highlighter", this);

This needs to be done each time after loading a new URL. Thankfully, QWebFrame has a signal telling us when it’s needed: QWebFrame::javaScriptWindowObjectCleared().

connect(m_webPage->currentFrame(),
        &QWebFrame::javaScriptWindowObjectCleared,
        this, &Highlighter::addJSCallback);

The implementation of the callback is straightforward:

// Header file
Q_INVOKABLE void setHighlightCompleted(bool success);

// Source file
void Highlighter::setHighlightCompleted(bool success)
{
    emit highlightCompleted(success ? parseHighlightedHtml() : plainTextCode());
}

As a last step, we modify the SHJS code slightly, to call this function when it’s completed:

highlighter.setHighlightCompleted(true);

The parseHighlightedHtml() function used above, simply parses and returns the HTML code between <pre class="sh_cpp"> and </pre>, which is now full of <span> tags generated by SHJS. Combine this with the SHJS stylesheet and we have our highlighted C++ code!

The above described method is used for highlighting C++, Python, XML, JavaScript and Java code. For QML code, we had to take a different approach, as SHJS has no built-in support for QML. Instead, we use a Python script that, similarly to SHJS above, gives us HTML code with <span> tags to combine with a stylesheet.

The post Code highlighting in SlideViewer appeared first on KDAB.

Adapting SlideViewer to Qt Quick Controls

Several previous posts have introduced our SlideViewer tool which we created for use in the various trainings we deliver. The tool started out as an experiment, created using basic QtQuick 2 Items. Startup configuration was specified by command line arguments, and a simple Keys.onPressed function provided most of the runtime control: both navigating around the slide deck but also more advanced functions such as reloading the slide deck and toggling fullscreen mode.

While the above was sufficient for developers, it was unsuitable if we ever wanted to give SlideViewer to non-technical people as a packaged application – and some developers do prefer to use a real GUI too! Hence the aim was to give SlideViewer a menu-bar and dialogs, using the features available in Qt Quick Controls.

First Attempt

My initial change was to add a Menubar item to our existing Item hierarchy, with some
Menus and MenuItems:

    MenuBar {
        id: menuBar

        Menu {
            title: "&File"
            MenuItem { text:"Open" }
        }

        Menu {
            title: "&Go"

            MenuItem {
                text: "&Next slide"
                shortcut: "Right"
                onTriggered: _slideDeckController.incrementPage(1)
            }

            MenuItem {
                text: "&Last slide"
                shortcut: "End"
                onTriggered: _slideDeckController.gotoSlide(_slideDeckController.total,0)
            }
        }
    }

This actually worked on Mac, where we use native code to create and define the menu-bar. But actually MenuBar is supposed to live within an ApplicationWindow element in QtQuick. ApplicationWindow inherits from Window, but is not an Item – so this entailed some changes in the top-level QML element.

Using an ApplicationWindow

Item {
  id: rootWindow
  Item {
    id: content
    // .... all the SlideViewer window content
  }
}

… becomes this …

ApplicationWindow {
  id: rootWindow
  Item {
    id:content
    // .... all the SlideViewer window content
  }
  MenuBar {
    Menu {
      ...
    }
  }
}

But more importantly, it entailed some changes in C++. QQuickWindow is a QWindow, and expects the QML file it loads to define a root Item. But with the new structure above, the root element in our QML is a Window. We need a QML / QtQuick engine which expects us to load window – and fortunately, it exists: QQmlApplicationEngine.

Setting up the application engine is very similar to a QQuickWindow:

QQmlApplicationEngine appEngine;
appEngine.addImportPath(":/qml");
appEngine.load(QUrl("qrc:///qml/SlideViewer/SlideViewerWindow.qml"));

Because we want to manipulate the application window from C++, we use the rootObjects method of the engine to find our application window:

Q_ASSERT(!appEngine.rootObjects().isEmpty());
QQuickWindow * const rootWin = qobject_cast<QQuickWindow*>(appEngine.rootObjects().front());
Q_ASSERT(rootWin);

Actions, always actions

The next problem is that we’re duplicating logic between MenuItems and the Keys.onPressed logic that already existed. The solution in QtQuick Controls is analagous to that in widget-based applications: actions! QAction from C++ is tied to the widget classes, so it can’t be exposed to QtQuick; instead we have a very similar Action item in Qt Quick Controls. As you would expect, you can supply the name, icon, keyboard shortcut and triggered behaviour of each Action once, and then refer to the Action from a MenuItem. Actions also work in toolbars, but SlideViewer doesn’t use those for now.

Action {
  id: printAction
  text: "Print"
  shortcut: "Ctrl+P"
  onTriggered: _printer.start()
}
MenuBar {
  Menu {
    ...
    MenuItem { action:printAction }
    ...
  }
}

Adding a dialog

Having made these changes, adding some dialogs was straightforward (at least for the
complexity needed by SlideViewer) – here is our SettingsWindow.qml:

ApplicationWindow
{
  ColumnLayout {
    anchors.fill: parent
    Checkbox { id:skipHandoutPages; text: "Skip handout pages" }
    Checkbox { id:showClock; text: "Show clock" }
    RowLayout {
      anchors: { bottom: parent.bottom; right:parent.right}
      Button {
        text: "OK"
        onTriggered: ....
      }
    }
  } // of column layout
}

Composing buttons and checkboxes using column and row layouts, and mixing QtQuick Controls layouts with standard QtQuick anchors, works nicely.

Finishing up

There is one final piece to avoid long startup times and increased memory footprint, as we add more dialogs: in a widgets-based application it would be unusual to create all dialogs at startup. Similarly for QtQuick we want to defer loading the QML for a dialog until it’s shown. The solution to this is of course the trusty Loader item.

The final result is SlideViewer is now approaching something we could package and deploy to non-technical users, without needing to explain command-line arguments to them, or memorise keyboard shortcuts. From the developer side we did need to restructure some things; if the codebase was larger, these changes could have been painful. Transitioning from a prototype to a real application UI is not something to leave until the day before ship!

This was my first experience using Qt Quick Controls, and for this scale of application they worked well – definitiely a viable alternative to using widgets.

The post Adapting SlideViewer to Qt Quick Controls appeared first on KDAB.

Re-introducing QicsTable

QicsTable is a full-featured, high-performance table widget suited for use in industrial-strength applications. It incorporates a model-view-controller architecture, so that multiple table widgets can display the same data. The QicsTable widget has extensive printing capabilities, including the ability to print the table with different visual characteristics than the on-screen table display.

KF5 in Yocto

KDE recently released the first version of KDE Frameworks 5, or shorter KF5. This is a set of add on modules extending and improving Qt, forming the base on which the Plasma Desktop is built. The nice thing is that KF5 is very modular and very reuseable.

Recently I’ve spent some time working with Yocto (yes, the series will continue – I just need time to do a couple of clean builds). So, I thought this was the perfect little summer vacation project for me. So, the plan is to package one module a day of KF5 for Yocto. The layer resides on github as meta-kf5.

This is a release early, release often project, so I’ve just gotten KAchive and ECM integrated. You can follow the progress from the project status page.

Qt Creator 3.2 beta released


We are happy to announce the Qt Creator 3.2 beta today. So you can already check out the many improvements we have done for the upcoming 3.2 release, and, not to forget, give us feedback on what we have so far. We mostly concentrated on stability and improvements, so no completely new platform supported this time, sorry ;) . I’ll randomly highlight some of the changes here, but you should probably check out our change log as well for a more thorough overview, and just download the binaries and try it for yourself.

In the text editors you can now do “column editing” in block selections, so typing in a block selection will adapt all lines simultaneously. Context help can now be configured to open in an external window (without disabling Help mode). When opening the same file in multiple splits, the editors will now keep showing the same part of the file, even when adding or removing lines in another split. There were also many fixes in the C++ model, including support for C99 designated initializers, concatenated strings, and fixes for encoding issues.

In the debugger views, you can now expand and collapse columns by clicking on the header. There were several types added to the debugging helpers, and if you are brave, you can now also provide your own debugging helpers for your own types. The QML profiler received many performance and stability improvements again. Enterprise users can now debug their JavaScript memory usage in QML, using the new memory profiling feature of the QML profiler. (This is only available when using Qt 5.4.)

You find the opensource version on the Qt Project download page, and Enterprise packages on the Qt Account Portal. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

Note: With Qt Creator 3.2 we drop support for OS X 10.6 (Snow Leopard). The technical reason for this is that Apple does not support any kind of C++11 on that OS version. Of course that does not affect on which platforms you can run your Qt applications on. But it is not possible to run the Qt Creator 3.2 binaries on 10.6, and it also is not possible to compile Qt Creator 3.2 on 10.6 with the tool chains provided by Apple.

Rapid Development of an In-Vehicle Infotainment System (IVI): A UX Perspective

With the recent announcements of Apple’s CarPlay® and Google's Android Auto In-Vehicle Infotainment Systems (IVI), in-vehicle systems in general have recently been pulled from relative obscurity into the limelight. IVIs are becoming a much more integral part of everyday life with people spending more and more time in their cars. Having an easy to use system that integrates with technology you are already using (e.g., Smartphone, MP3 player, Tablet, etc.) lets you better enjoy your driving experience.

Qt Contributors’ Summit 2014 sum up


Lars opening speech

Lars making the opening speech

It’s almost a month since we gathered at the Estrel Conference Center to spend two days talking about Qt, where it is and where it’s heading.

The Summit started off with Lars Knoll giving the state of the project speech, which included status updates from various maintainers. The whole opening session can be watched on Youtube. One thing to raise from Lars’ speech is the need to unify Qt, to bring all Qt users closer to each other.

The two days contained over forty sessions on matters ranging from the use of box2d with QML to two sessions on QtCore. You can find many of the session notes from the Summit schedule page. And the more technical topics have threads on the Developer mailing list, which you can find from the list archives (search for threads marked QtCS).

Session ongoing

Over 40 sessions in two days

The weather in Berlin was exceptionally hot, bordering on uncomfortable outside. Luckily the conference center had good air conditioning. However during the evening event we could enjoy the warmth outside in the garden. The setting was very good for continuing the discussions that started during the day. The hardiest participants continued their discussion at the hotel lobby bar after the official evening event was closed.

Evening event

Evening event

A big part of events like the Contributors’ Summit are the coffee break and corridor discussions that take place in between sessions. The venue provided enough tables and a couple of good corners with benches to spend some time drafting the upcoming session agenda or working on the topics raised in previous sessions.

Showing app

Coffee break application demo

A big thank you to all the participants and of course to our sponsors!

Hope to see many of you at the Developer Days!

Making an Android device boot to Qt


Android Injection

Qt Enterprise Embedded provides pre-built system images for a range of popular devices, like the Nexus 7 tablets and the BeagleBone Black. With these, you can make your device “boot to Qt” and be up and running with embedded development literally within minutes. But what if you want to try a device that is not among these reference devices of Qt Enterprise Embedded? Until recently, as an evaluator, you were basically out of luck. And even with an Enterprise license, you would have to rebuild the image from scratch for your device, a process that can take some time. Now, with the recent update of Qt Enterprise Embedded, there is another option available. If your device runs a recent version of Android, it is now possible to install the Boot to Qt stack directly into the existing Android system image; in effect taking it over. We call this method Android injection. In this blog post we will show how this process works in practice. We will use a device called the ODROID-U3 as our example.

odroid-box

The Injection Steps

The installation process consists of the following:

  1. Unpacking the Boot to Qt system and data archives into the /system and /data folders of the Android system
  2. Creating a device configuration file, appcontroller.conf
  3. Changing the Android boot script (init.rc) to make the device boot to Qt instead. We provide a script to perform the necessary changes.

As you can see, this is not very complicated. However, it cannot easily be automated, since  every device has different ways of packing the file systems and boot files. So a little manual effort is required.

The ODROID-U3 Device

This device is created by Hardkernel and has a quad-core Cortex-A9 processor, Mali-400 graphics processor and HDMI display output, and Android builds are available. For the injection process, any Android 4.2 or 4.4 image should do. For this blog post, I downloaded the Android 4.4 SD card image from here, and installed is as explained here. After booting twice, the device runs Android fine:

odroid-android

1. Unpacking the Boot to Qt system and data archives

The bulk of the Boot to Qt injection stack comes in the form of two tarballs, intended to be unpacked into Androids /system and /data folders respectively. On most Android distributions, those folders have separate partitions on the storage device. We need to determine which partitions that is. One way is to log in to the device and study the /fstab file, which will show where the partitions will be mounted. Like this:

~/odroid$ adb shell cat /fstab.odroidu.sdboot
# Android fstab file.
#                                                              
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

/dev/block/mmcblk0p2    /system             ext4      rw                                                    wait
/dev/block/mmcblk0p3    /data               ext4      noatime,nosuid,nodev,nomblk_io_submit,noauto_da_alloc,errors=panic    wait
/dev/block/mmcblk0p4    /cache              ext4      noatime,nosuid,nodev,nomblk_io_submit    wait
/devices/platform/s3c-sdhci.2/mmc_host/mmc0 auto    auto    defaults voldmanaged=sdcard0:1,noemulatedsd
/devices/platform/dw_mmc/mmc_host/mmc0      auto    auto    defaults voldmanaged=sdcard1:auto
/devices/platform/s5p-ehci                  auto    auto    defaults voldmanaged=usbdisk:auto

As we see, in this case /system and /data are on partitions 2 and 3 respectively. After powering down the device, and plugging the SD card into the host PC where the Qt Enterprise Embedded SDK is installed, we are ready to do the unpacking. Here, the SD card appears as /dev/sdb, and the SDK is installed in ~/QtEE31:

~/odroid$ mkdir p2
~/odroid$ sudo mount /dev/sdb2 p2
~/odroid$ sudo tar x -C p2 -f ~/QtEE31/Boot2Qt-3.x/generic-4.4-eAndroid/images/system.tar.xz 
~/odroid$ mkdir p3
~/odroid$ sudo mount /dev/sdb3 p3
~/odroid$ sudo tar x -C p3 -f ~/QtEE31/Boot2Qt-3.x/generic-4.4-eAndroid/images/data.tar.xz

# Checking that things look good so far:

~/odroid$ ls -l p2/bin/qtlauncher
-rwxr-xr-x 1 root root 173420 Jul  1 21:41 p2/bin/qtlauncher
~/odroid$ ls -ld p3/user/qt
drwxr-xr-x 21 root root 4096 Jul  1 21:41 p3/user/qt/

2. Creating a device configuration file

The Boot to Qt stack needs a few environment variables and other device-specific settings. These are stored in plaintext format in the file /system/bin/appcontroller.conf. (Granted, that is not the most natural place for a settings file, but for now, that is where it is). One can see examples for different reference devices in the directories in Boot2Qt-3.x/generic-4.2-eAndroid/images. For the ODROID-U3, we store the following in p2/bin/appcontroller.conf:

#env=QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event0
env=QT_QPA_EGLFS_NO_SURFACEFLINGER=0
env=QT_LOGGING_TO_CONSOLE=1
env=QML2_IMPORT_PATH=/data/user/qt/qmlplugins
env=QT_IM_MODULE=qtvirtualkeyboard
base=android
platform=odroidu

Since we do not have a touch screen connected, the line setting the touch screen device has been commented out.

3. Changing the Android boot script

This step can sometimes be a little tricky. The boot script (init.rc) is always in Android’s root file system. But many Android distributions package the kernel and the root file system into a special binary boot image format, and place that in a separate partition. That partition is then not mountable and modifiable like a normal file system. Instead, special scripts must be used to unpack it and repack it after modification. One can easily search up information about the process on the net.

In other cases, the boot script is available as a plain file. That is the case for our sample device, we find the ODROID’s init.rc
file in the root directory of partition 2. The modification process itself is made very simple by a script provided in the Qt Enterprise Embedded SDK:

~/odroid$ sudo cp p2/init.rc p2/init.rc.orig
~/odroid$ sudo sed -f ~/QtEE31/Boot2Qt-3.x/generic-4.4-eAndroid/images/generic/modify_init_rc.sed -i p2/init.rc

# Checking that the modification succeeded:

~/odroid$ tail -1 p2/init.rc
    start boot2qt

Ready to rock!

All that remains is to unmount the SD card:

~/odroid$ sudo umount p2
~/odroid$ sudo umount p3

Now, with trembling fingers take the SD card with your brand new Boot to Qt image and plug it into the device. Then apply the power supply and wait for the screen of success:

odroid-b2qt
(If your device should not start up like this, try to look for error messages in the output from adb logcat and adb shell appcontroller qtlauncher.)

At this point, it is easy to set up your linux host and Qt Creator for one-click deployment of your apps to your device. Just follow the simple instructions for “Setting up USB Access” and “Configuring a Device Kit in Qt Creator” in one of the Android device preparation pages. Then, you are all set to start Building and Running Embedded Applications!

Introducing Android Injection with Qt Enterprise Embedded 5.3.1


We released Qt 5.3.1 a week ago and now we’ve updated the Qt Enterprise Embedded offering as well. In addition to the Qt framework upgrade, we have developed a few new interesting features and also updated the tooling and some of the enterprise add-on features. We are especially proud about our new Android injection solution that lets you take the Boot to Qt software stack into a large variety of Android devices with little effort.

With this update we are also introducing the first Qt supported CoM, Computer-on-Module, for embedded Linux as we announce official support and pre-built binaries for Apalis i.MX6 CoM module from our Qt Technology Partner Toradex. Using the Apalis i.MX6 module from Toradex with our pre-built Qt stack, you can reduce the needed HW and SW effort enabling fast and cost-efficient creation of various embedded systems directly leveraging the state-of-the-art features of this powerful combination.

Qt 5.3.1, Qt Creator 3.1.2, Qt Quick Compiler 1.0 and an updated Qt WebEngine

Qt Enterprise Embedded comes with the pre-built Boot to Qt software stack, now built using Qt 5.3.1, which allows you to immediately start prototyping and developing your product. And if you happen to need some changes to the stack as well, don’t worry; you can easily modify the stack with the provided tooling.

Today’s update includes a fully supported Qt Quick Compiler 1.0. The Qt Quick Compiler takes the declarative QML files and compiles them into native code, thus improving application load times significantly. With Qt Quick Compiler the typical Qt Quick application load times are reduced by 30%-40%, with maximum gain being up to 90% with highly JavaScript intense applications.

The Qt Creator IDE has also received bunch of enhancements through an update to Qt Creator 3.1.2.

Qt’s all-new Chromium-based web engine was first introduced as part of Qt Enterprise Embedded in the previous release. With the received feedback, we are bringing in some enhancements and bug fixes to Qt WebEngine as well. With this release we enabled multi-process support for eAndroid as well, and added support for the new generation Nexus 7 (2013) as a new device. Besides that QtWebEngine received a lot of stability and other bug fixes having an effect on both the eAndroid and eLinux configurations.

Take “Boot to Qt” Anywhere with New Android Injection

So far we’ve distributed pre-built images of the Boot to Qt software stack for a set of reference boards and separate tooling to customize the contents and target hardware. For embedded Linux, we’re providing the recipes for Yocto project tooling to do the customization.

Now, we are introducing a whole new Build-Your-Own-Device tooling for embedded Android that works through an injection model. This means that instead of flashing a device with a complete stack, the Boot to Qt contents are injected into an existing Android image on a device.

The effect is that almost any recent, programmable Android device can be turned into an embedded Qt-powered device with little effort. This makes your set of potential prototyping devices huge and lets you conveniently do small batch production devices with low-cost bulk Android hardware.

To read more about how this works in practice, check the separate blog post.

First Qt Reference CoM with Toradex Apalis i.MX6

We are proud to introduce our first CoM, Computer-on-Module, reference platform for embedded Linux. CoM is a complete embedded computer on a single circuit board, which can easily be integrated into a custom embedded hardware design.

Usage of CoM in your embedded hardware makes maintainability and upgradability a lot easier when compared to more traditional fully-integrated embedded hardware solutions.  It also reduces hardware development time significantly, allowing you to focus on things that really matter to you on hardware design, leaving the processing unit design complexities out of the picture. When combining this with the Qt Enterprise Embedded offering, you will have your devices ready for market in no time.

Toradex Apalis i.MX6 is a leading-edge embedded CoM, based on quad core Freescale i.MX6 SoC, System-on-Chip. Apalis i.MX6 supports a wide variety of industry standard interfaces, high speed connectivity and advanced multimedia features making it an ideal choice for even most demanding embedded system designs.

Updated Value-Add Components

Virtual Keyboard 1.1

The Qt Virtual Keyboard has received a minor update that brings in more keyboard layouts, Chinese input, sound feedback and 5-way navigation that allows you to use the virtual keyboard with a hardware input device (such as a joystick/scroll-wheel). Read more about the 1.1 version in the separate blog post.

Data Visualization 1.1 and Charts 1.4

Both Data Visualization 1.1 and Charts 1.4 contain a lot of improvements and new features requested by our customers.

The most important improvements in Data Visualization for embedded customers are the performance optimizations. Data caching is now optimized when only a part of the data changes. In addition there are also some experimental optimizations. Also Charts 1.4 includes a bunch of improvements and new features. For example, QML API has been improved to make it easier to use Charts in Qt Quick applications.

More details about these releases is available in blog post.

Further information

Further information can be found in the product page, from the change log and in the Qt Enterprise Embedded documentation.

Getting Started

You can update your product using the package maintainer, download a new version from Qt Account or request a Free 30-day trial via the Try Now page to get started with Qt Enterprise Embedded.

To help you get started you can take a look at our recent webinar recording that introduces Qt Enterprise Embedded in action:

Qt Virtual Keyboard 1.1


The initial version of the Qt Virtual Keyboard was released earlier this year, and has quickly become a popular value-add component amongst our Qt Enterprise customers. We are continuously developing it and are now releasing version 1.1, which brings support for Chinese input, 5-way navigation, sound feedback and adds new layouts (languages).

With version 1.1 of the Qt Virtual Keyboard, we are happy to announce that we have made it possible to input Chinese characters using pinyin. Needless to say, this has been a highly requested feature, we are happy to have included.

"Hello World" in Chinese

“Hello World” in Chinese

Layouts for Polish and Swedish are also added to the already quite long list of included layouts, such as English, German, French, Spanish, Italian, Russian, Portuguese, Finnish and Arabic. You can extend the keyboard with more languages yourself, and we will of course be adding more for you in upcoming versions. Korean and Japanese are on the product backlog, and I think Norwegian might be a hot candidate too. ;-)

Not all embedded devices have a touch screen, and might instead be controlled by a remote control, joystick or similar. Thanks to the newly added 5-way navigation, it is now easy to use the Qt Virtual Keyboard using such controls in addition to or instead of touch.

Last, but not least, we have made it possible to add sound, so that the end user can receive feedback whenever a key is pressed.

This was just about the newly added features. For the full description of what the Qt Virtual Keyboard is about, please take a look at the product page.

The Qt Enterprise Virtual Keyboard is licensed under Qt Enterprise, it can be easily included into all kinds of embedded devices without concerns for 3rd party license compatibility.

You can download the Qt Virtual Keyboard from the Qt Enterprise Customer Portal, it is also part of the just released new version of Qt Enterprise Embedded, and you can install it through the Qt Enterprise Embedded online installer.

If you are not already a Qt Enterprise customer, check out our free 30-day evaluation.

Qt Weekly #16: QQuickWidget


Combining Qt Quick 2 scenes with traditional QWidget-based user interfaces is a good path to choose if you want to transition your exisiting application to use more of the cool new functionality that Qt Quick provides. While Qt 5.2 introduced QWidget::createWindowContainer() for embedding native windows as a regular widget, a number of limitations remained: Most notably the inability to have a well-defined stacking order and various surprises regarding focus handling, drag and drop, etc., depending on the platform.

Such issues may sound familiar also to those who are working with the good old QGLWidget. It seems to work fine – until it becomes part of a more complex UI, gets added to scroll and MDI areas, and gets combined with overlapping widgets. At that point unexpected issues, like painting problems, artifacts and broken input, start to surface. The fact that such widgets are in practice native windows – and turn their ancestors and siblings native too – is hidden from the developer, even though this has consequences.

On Embedded Linux or Android devices that run without a windowing system, using the eglfs platform plugin, the situation is even less ideal: Combining a QQuickWindow or QGLWidget with other widgets will simply abort the application because there is no support for creating multiple, non-fullscreen native windows and surfaces. For plain QWidget windows, that are fully rendered in software, this is not an issue since they can easily be composed and blitted onto the single window surface covering the entire screen. However for OpenGL-based windows there is no workaround.

To overcome all this, a set of new widgets are being introduced. The first in the series is QQuickWidget, introduced in Qt 5.3.

As the name suggests, this, as opposed to QQuickWindow and its convenience wrapper QQuickView, is a regular QWidget-derived class. Unlike QGLWidget, it carries no surprises: this is like a normal widget, no native windows will get created behind your back. This comes at a minor cost of course: the OpenGL rendering of the Qt Quick scene is done into a framebuffer object. The compositing is handled transparently by the widget stack.

Speaking of transparency, QQuickWidget retains one limitation: Placing other widgets underneath it and making the QQuickWidget (semi-)transparent will not lead to the expected result. On the bright side, putting widgets on top will function as expected, as will everything else. To demonstrate this, consider the little example that is going to be added to Qt 5.3.2:

First, let’s try using a QQuickView. The application uses regular widgets, with the QQuickView being embedded via QWidget::createWindowContainer(). This, besides not working at all on embedded, has the unfortunate consequence of not being able to show a semi-transparent overlay widget on top.

The code to create the QQuickView is the following:

    QQuickView *quickView = new QQuickView;
    quickView->setResizeMode(QQuickView::SizeRootObjectToView);
    connect(quickView, &QQuickView::statusChanged, this, &MainWindow::onStatusChangedView);
    connect(quickView, &QQuickView::sceneGraphError, this, &MainWindow::onSceneGraphError);
    quickView->setSource(source);
    m_layout->addWidget(QWidget::createWindowContainer(quickView));

 

qqw_ex_qquickview
This does not look quite correct.
Now let’s switch to QQuickWidget.

The code is very similar. The QQuickWidget API mirrors QQuickView. createWindowContainer() is not needed anymore since QQuickWidget is a plain old QWidget.

    QQuickWidget *quickWidget = new QQuickWidget;
    quickWidget->setResizeMode(QQuickWidget::SizeRootObjectToView);
    connect(quickWidget, &QQuickWidget::statusChanged, this, &MainWindow::onStatusChangedWidget);
    connect(quickWidget, &QQuickWidget::sceneGraphError, this, &MainWindow::onSceneGraphError);
    quickWidget->setSource(source);
    m_layout->addWidget(quickWidget);

 

qqw_ex_qquickwidget
This looks much better. And works on embedded too!
To summarize:

  • Use QQuickWidget when the Qt Quick content is embedded into a widget UI or when there is a need to place widgets on top. The more complex the interface gets, the bigger the chance of encountering issues with native child windows becomes. Hence the general recommendation is to always use QQuickWidget in widget-based applications.
  • Use a standalone QQuickWindow or QQuickView when widgets are not needed and maximum performance is desired. On desktop platforms applications are of course free to open additional widget-based top-level windows when necessary.
  • Never use QWidget::createWindowContainer().
    (Well, unless there is a very good reason for using it and you know what you are doing. If the stacking and other limitations do not apply and the application is targeting desktop platforms only and the platform in question is able to use the Qt Quick Scenegraph’s threaded render loop, then having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget)

Future Qt versions are likely to bring similar new classes, first and foremost a modern replacement for QGLWidget, so stay tuned.

Summer time is upon us here in the northern hemisphere. The Qt Weekly blog post series will therefore take a few weeks vacation. See you back in fall!

Touch Gesture Success and Screen Angle for an Interactive Kiosk

When installing a touchscreen kiosk, the angle of the screen is a major consideration. First, it affects how quickly people perceive the device as interactive and also touch-enabled. (See my   previous  post, Is That a Kiosk? How to Best Position Your Public Touchscreen Display for Use.) Second, it affects how comfortable it is for users to perform touch gestures.

Analysing QtQuick apps with GammaRay or “Why is my button gone?”

This is a typical situation when you program a GUI for an application. You have just created a new control, you start your application and… no control. But now: Is it obscured? Is it misplaced? Is it completely transparent or set to ‘invisible’? Is my custom OpenGL-stuff broken or is the item actually not created for some reason? Checking all these cases manually can be a time-consuming and exhausting task.

“Come on, it’s got to be easier than this!”

In the web-development world people are used to tools like Firebug or the Chrome developer tools, which allow you to debug websites, showing you the HTML tree with CSS properties and highlighting selected elements. They cover exactly this use case.

In the Qt-world we have GammaRay, the Qt introspection tool, to make our lives easier in regard to real-time analysis of applications. Just as you can introspect the skeleton of a human with an X-ray unit, so you can introspect the skeleton of Qt applications with GammaRay. GammaRay is able to show you the internal tree of QObjects and their status and even allows you to manipulate the application’s state in real time.

One of the many handy tools GammaRay provides is a module for analysing QWidget based GUIs. You can select widgets, check their position and visibility, etc. A similar tool exists for GUIs based on QGraphicsView. The recent version 2.1 release of GammaRay completes the collection of GUI-tools with a tool for inspecting QtQuick2 applications.

GammaRay Quick inspector

The new GammaRay Quick inspector in action

Let’s check how it will help us track down all the possible causes for the absence of our button…

“Could it be that it doesn’t exist at all?”

The tree of Items in the QtQuick scene

There is an item called ‘backButton’ so it does exist, at least.

The most basic feature of GammaRay’s Quick inspector is the tree view of all QQuickItems in the item tree. You will discover it on the left side of the UI. Apart from answering the most basic question “Which items do exist?” and providing navigation, it will already provide you with some additional information:

  • “which items are actually visible?“ (items with visible == false will be greyed out)
  • “which item has focus?” (More on that later on)
  • it will warn you if it suspects something is wrong with the items (e.g. Items that are outside the visible area, but still have visible == true are either misplaced or unnecessarily slow down rendering)
  • it will discreetly highlight items that receive events (you will discover a subtle purple text color, fading back to black after you e.g. click on a mouse area)

“Could it have set visible == false or opacity == 0?”

The property view for a QQuickItem

It’s visible at least.

If you have used GammaRay before, this one will be familar to you. Right to the item-tree there is a detail-view, providing information about the state of the item. Just as in the object inspector, you can:

  • see all the properties with their values (hint: since 2.1 you can right-click QObject* properties to get a detailed view in the appropriate tool) and change them inline
  • inspect signal-slot connections and log signal-emissions
  • directly invoke slots and Q_INVOKABLE methods
  • check Qt-known enums and
  • class-info data

Any changes you make to properties in GammaRay will directly influence the original app, so you can easily turn a green rectangle red or set an item invisible to check what’s below it.

“Might it be size ‘zero’ or misplaced?”

geometry displayed in the scene-preview

Oh hey, it’s the left anchor line, that’s aligned to parent.right. That should be the right anchor!

The Quick inspector tool has a live-preview of the QtQuick scene inside the GammaRay window. Here you can:

  • zoom in to a specific area and measure distances in the scene in order to achieve pixel-perfect UIs.
  • send mouse and key events to the app, so you can control it remotely. This especially comes in handy, if you need to debug a device, that does not lie directly besides you.
  • activate some cool hidden debugging features, QtQuick ships by default (more on that later on).
  • easily check the geometry and positioning of an item.

The last-mentioned feature is what you need to answer our question if the geometry is right. If you select an item in the item-tree above, the preview will be annotated with information about geometry and layouting of that selected item. The item’s bounding rect is highlighted in red. Anchor-layouts, including margins and offsets or x/y offset, are displayed graphically, depending on whatever is used for layouting. Transformed items will additionally have the original size and position displayed as well as the transformation origin.

“Is it possibly obscured?”

QSG_VISUALIZE=overdraw activated from GammaRay

Fancy and useful animation triggered from GammaRay

GammaRay has quite some helpful tools for debugging QtQuick applications. But it is not the only one. QtQuick itself already provides some very cool stuff for debugging, though most of it is quite hidden.

Since Qt 5.3, one cool feature the QtQuick scenegraph has, is visualizations for various things directly inside the application using the environment variable QSG_VISUALIZE set to either “clip”, “overdraw”, “batches” or “changes”. One of them (overdraw) helps to spot items that are completely or partly obscured by other items.

It does not make sense for GammaRay to reinvent the wheel here and recreate the same features, but GammaRay can make them available and even enhance them by making them triggerable in real-time. The toolbar in the top-left corner of the preview contains icons to en- and disable the visualize$STH render modes dynamically. See the link for more information about this scenegraph-feature.

“Or is the scenegraph or OpenGL stuff of my custom item broken?”

OpenGL Vertices drawn as wireframe in Scenegraph Geometry tab

Ever wanted to know, how OpenGL draws a circle? It’s all triangles.

When writing complex, fancy QtQuick applications, you might at some time come to the point, where you need a custom item type, with its own geometry, textures and shaders. QtQuick provides tremendous flexibility here, while still hiding it behind a very nice API, in case you don’t need it. Everything you can do with OpenGL is possible.

With all the possibilities of OpenGL comes all possibilities of mistakes. In fact on the OpenGL side almost the same questions reappear: Does the scenegraph node exist? Are the properties correctly set? Is the geometry correct? What do the shaders do?

While being a full OpenGL debugger is out of scope for GammaRay, (there’s apitrace and vogl for that), providing some high-level insights into the scenegraph nodes and their OpenGL properties is not. The tree view of items mentioned earlier has two tabs: “Items” and “Scene Graph”. “Items” shows the QQuickItems, as described above, “Scene Graph” shows the graph, that is generated by the QtQuick engine. Each item provides one or more scene graph nodes, that hold a transformation matrix, an opacity value, a geometry, textures and/or shaders. These nodes are then composed by the QtQuick renderer to a scene, that gets passed to the GPU for rendering.

As with items, you can use it to see if all nodes exist and check their basic properties. As soon as you select a Geometry Node, you will however discover two new tabs in the property-view:

  • Geometry: This tab displays a table of the raw OpenGL vertex data and uses the vertex coordinates as wireframe. You can check the vertex-positions and check the properties they will pass to the vertex-shader.
  • Shaders: This tab simply offers you the possibility to have a look at the shaders. It basically allows you to check whether the shaders are correctly set.

We already have a lot of ideas (e.g. list uploaded textures and set them in context, display in and output-values for the shaders, etc.), but this first batch of features already helps track down quite a lot of common errors.

Focus debugging – “Where does my key-press get stuck?”

Finally the GammaRay QtQuick inspector is not just all about finding missing buttons. Another common source of problems in the context of QtQuick, where tools have been missing so far, is focus. You have added a text edit, have set focus: true but when you run it, the text you enter arrives nowhere. You will want to know: “My item should have focus. Why doesn’t it have the active focus?” (hint: there’s a difference between focus and active focus) “Which item does have the active focus?” and finally “Where does my key press actually arrive?” (this is the active focus item in the first place, but if that doesn’t accept it, it will be passed on to its parent).

If you take a deeper look at the Item tree, you will find that some items have more than one small icon besides them, like a warning-icon or spotlight icons. While the warning icon states that there might be something wrong with this item (as mentioned earlier), the spotlight icons are the important bits for focus debugging. Basically the spotlight marks items, which have focus (focus == true). The turned-on spotlight icon marks the one item that has active focus (activeFocus == true) and thus actually will receive key events, while the turned-off spotlight marks items that have focus but no active-focus (like it has focus set to true but is on a hidden tab or on an inactive window and thus won’t receive events). These icons answer the first two question.

The last question is answered by another feature I mentioned in the context of the item tree view. It’s the small purple text highlighted on the items in the tree, when it receives an event. The color of the text turns to purple and fades back. This highlight is triggered on any kind of event, including mouse and key events. In this way, you can easily trace, which items receive your key-press.

Stop digging, start hacking again!

The post Analysing QtQuick apps with GammaRay or “Why is my button gone?” appeared first on KDAB.

Recap of the Qt Contributors Summit

The Qt Contributors Summit occurred June 10-11 in Berlin. Here is a quick summary of my impressions:

1) Unifying Qt

Qt Project is highly interested in unifying Qt Commercial offerings with Qt Open Source. This was a major point made by Lars Knoll in his keynote speech and there were two discussion sessions on the matter. 

Introducing Grapher

I just found myself in the situation where i need to be able to create bargraphs.

part-i

The design is fairly limited: a row of stacked bars with optional labels under and inside each bar.

part-ii

I also want to be able to color the bars.

part-iii

I wrote a quick little PyQt-based Python program. It lets you write things like this:

bs = BarGraphStack()
bg = BarGraph()
bg.setTitle("Image Size")
bg.addBar(Bar(6349, Qt.Qt.darkGray, "6 349KiB", "kernel(bz)"))
bg.addBar(Bar(25240, Qt.Qt.lightGray, "25 240KiB", "rootfs"))
bs.addBarGraph(bg)
i = bs.render();
# i is a QImage

You can get the latest source code from the Grapher github repository. It is probably obvious that this is Python code written by a C++ guy, but I hope that it still might be useful.

Now I need to add some steps to feed it data automatically, but that is for another day.

The Whole Shebang - Running QML Files Directly

A new feature in Qt version 5 is an executable program similar to qmlscene that can execute QML files. It is sometimes referred to as the QML Tooling or QML Run-time, although both of these terms are sometimes used to refer to other aspects of QML. A few colleagues mentioned to me that they were not familiar with this feature of Qt, so I thought it would make a good topic for a short blog post.

Qt Weekly #15: Visualizing data stored in Qt item models using Qt Data Visualization


Item models are a commonly used to store data in Qt applications, so the Qt Data Visualization enterprise add-on offers ready-made data proxies to facilitate the visualization of data stored in these models. The basic usage is the simple item model role to data item value mapping, but with Qt Data Visualization 1.1, more powerful options to map model data have become available.

Basic use cases

Direct one to one mapping

The most basic use case of one-to-one mapping is demonstrated in Qt Quick 2 Scatter Example, where the data we want to visualize is stored in a simple ListModel like this:


ListModel {
    id: dataModel
    ListElement{ xPos: -10.0; yPos: 5.0; zPos: -5.0 }
    ListElement{ xPos: -9.0; yPos: 3.0; zPos: -4.5 }
    // And so on...
}


To make a 3D scatter series out of the above data, we specify a ItemModelScatterDataProxy to map the data into a Scatter3DSeries:


Scatter3DSeries {
    id: scatterSeries
    ItemModelScatterDataProxy {
        itemModel: dataModel  // The source model for data
        xPosRole: "xPos"  // Map model role "xPos" value to data item X position.
        yPosRole: "yPos"  // Map model role "yPos" value to data item Y position.
        zPosRole: "zPos"  // Map model role "zPos" value to data item Z position.
    }
}

This results in the scatter series with one item per ListElement in the ListModel, where the coordinates are taken from the ListElement roles as specified by the above mapping.

3DScatter graph

Table controls

Another basic use case is having a table control such as QTableWidget and creating a visualization out of that. QTableWidget stores the data in an item model, which already has data sorted into rows and columns. This use case is demonstrated in the Item Model Example. Since the data is already in rows and columns, we don’t need to map roles for those when visualizing using a bar graph or a surface graph, making our proxy very simple:


QItemModelBarDataProxy *proxy = new QItemModelBarDataProxy(tableWidget->model());
proxy->setUseModelCategories(true);
QBar3DSeries *series = new QBar3DSeries(proxy);

We indicate we want to use the existing rows and columns by setting the property QItemModelBarDataProxy::useModelCategories. We don’t need to define a role for value mapping either, because Qt::DisplayRole is used by default.

QTableWidget visualization

 

Advanced usage

Search and replace

Sometimes the model data is not suitable for one-to-one mapping. A typical use case for this is extracting different portions of a timestamp role to map for rows and columns. For example, you might want each row to represent one year and the columns to represent months of the year. Item model proxies of Qt Data Visualization support this use case via search and replace functionality, which allows you to modify the role contents before mapping it. An example of this can be found in Qt Quick 2 Bars Example, where the data is in the following format:


ListModel {
    id: dataModel
    ListElement{ timestamp: "2006-01"; expenses: "-4";  income: "5" }
    ListElement{ timestamp: "2006-02"; expenses: "-5";  income: "6" }
    // And so on...
}

To parse the timestamp role into both rows (years) and columns (months), we utilize a proxy like this:


ItemModelBarDataProxy {
    id: modelProxy
    itemModel: dataModel
    rowRole: "timestamp"
    columnRole: "timestamp"
    valueRole: "income"
    rowRolePattern: /^(\d\d\d\d).*$/  // Pattern to capture the year in the timestamp
    columnRolePattern: /^.*-(\d\d)$/  // Pattern to capture the month in the timestamp
    rowRoleReplace: "\\1"
    columnRoleReplace: "\\1"
}

The role patterns above are regular expressions that match the entire content of the timestamp role and capture the desired portion, either the year or the month. Specifying “\\1″ as role replace indicates that we want to keep only the captured part of the role. For more information how search and replace using regular expressions works, see QString::replace function documentation.

Qt Quick 2 Bars Example

Dealing with multiple matches

When assigning data into rows and columns, sometimes more than one data item matches the given row/column combination. Depending on the use case, you might want to just take the first match, average the matches out, or add all matches together. Qt Data Visualization item model proxies introduce multiMatchBehavior property, which you can use to specify the desired behavior in case multiple data items in the source model match any row/column combination. An example of this can be found Qt Quick 2 Bars Example, where one option is to view yearly totals. The proxy to achieve this would be similar to the one above, except with two differences:


ItemModelBarDataProxy {
    // ...
    columnRolePattern: /^.*$/  // Match everything
    multiMatchBehavior: ItemModelBarDataProxy.MMBCumulative
}

By having a column role pattern that matches every data item means that we will only have a column on each yearly row, and there will be exactly twelve matches for each row. The cumulative behavior we specify indicates that all matching data item values should be added together into a single bar.

Qt Quick 2 Bars Example - Yearly totals

Visualizing data from the cloud

The Enginio module provides a convenient way to load data from the cloud into an item model, the EnginioModel, which means visualizing the data from the cloud is possible using Qt Data Visualization item model proxies. For example, suppose we have a weather monitoring application that stores weather data into the cloud and a separate client application, where we want to show a history graph of the stored data. In the client application you would do this to get the data from the cloud:


EnginioClient {
    id: enginioClient
    backendId: "my_weather_data_backend_id"
}
EnginioModel {
    id: enginioModel
    client: enginioClient
}
function queryHistory(startDate, endDate, enginioModel) {
    enginioModel.query = {
        "objectType": "objects.weatherRecords",
        "query": {
            "createdAt": {
                "$gte": {
                    "$type": "time",
                    "$value": startDate
                },
                "$lt": {
                    "$type": "time",
                    "$value": endDate
                }
            }
        },
        "limit": 500
    }
}

Suppose we want to display the data with each row representing the day and each column representing the hourly average of measurements. The data proxy to display this data would be like this:


ItemModelBarDataProxy {
    columnRole: "createdAt"  // example createdAt role content: "2014-04-29T13:51:02.787Z"
    rowRole: "createdAt"
    valueRole: "outdoorTemperature"
    itemModel: enginioModel
    rowRolePattern: /^\d*-0?(\d*)-0?(\d*)T.*/i  // Capture the month and the day
    columnRolePattern: /^\d*-\d*-\d*T0?(\d*):.*$/i  // Capture the hour
    rowRoleReplace: "\\2.\\1."  // "day.month.", e.g. "12.6."
    columnRoleReplace: "\\1"  // Just the hour
    multiMatchBehavior: ItemModelBarDataProxy.MMBAverage
}

weather client screenshot for blog

 

 

Qt 5.3.1 Released


I am happy to announce that today we released Qt 5.3.1. Qt 5.3.0 has been well received with over 500.000 downloads in the first 5 weeks of release. I believe this new patch release is even better offering many improvements over Qt 5.3.0. As a patch release, it does not add new features, but various improvements and fixes. Qt Creator version 3.1.2 also released today, is packaged into the installers. For Qt Enterprise users we are providing a fully supported Qt Quick Compiler 1.0.0, as well as updates for Data Visualization (version 1.1) and Charts (version 1.4).

The focus of Qt 5.3 has been in stability and usability, and we have continued this trend with the improvements now released with Qt 5.3.1. Qt 5.3 introduced  a nice set of features, such as QQuickWidget, Qt WebSockets module, Purchasing API, Compiled Qt Quick, support for WinRT (and Windows Phone), as well as many others. Many of these features have been made even better in Qt 5.3.1 based on feedback received from customers and the whole Qt community.

Improvements in Qt 5.3.1

Overall Qt 5.3.1 contains more than 800 changes compared to Qt 5.3.0, and the most interesting ones depend on what you are creating and which platforms you are using, so I have listed some of the highlights:

  • Performance optimizations for Qt Quick Engine’s JIT compiler code generation and important bug fixes, especially on ARM (QTBUG-39289)
  • QAbstractProxyModel::sibling to now works in the same manner as with Qt4
  • Many small fixes to Qt Quick Controls, for example to TableView, TabView, ComboBox and Calendar
  • QQuickWidget now works properly also with ANGLE (QTBUG-39699)
  • Qt Quick animations now work also with static builds (QTBUG-37341)
  • Fix for a regression of QPushButton with QMenu (QTBUG-38550)
  • Fix for a regression on Mac for passing click event to underlaying widget (QTBUG-39322)
  • Initial support for Mac OS X 10.10, more improvements will land on upcoming Qt releases
  • Positioning backend now available also for Windows Phone
  • Accessibility now works on Android also below API level 18 (QTBUG-39508)
  • Fix flashing white screen at startup/shutdown on Android (QTBUG-38960)
  • Support for upcoming Android L (QTBUG-39042)

Change logs of the most important new items are located within each module, and we have collected some of the Change files for Qt 5.3.1 into wiki.

You may also want to check the Known issues for Qt 5.3.1.

Qt Quick Compiler 1.0.0 – Startup is 30-40% Faster

The new Qt Quick Compiler we introduced with Qt Enterprise 5.3 is now available as a fully supported 1.0.0 version. The Qt Quick Compiler takes QML files and compiles them to native code improving run-time performance on operating systems where one cannot use a just-in-time compiler, such as iOS and WinRT.

The compiler is also very useful for improving the load times of QML, as all of the parsing work now happens at compile time. This is especially interesting for startup times of applications and boot times of devices using Qt Quick for the user interface. Our measurements indicate that a typical mid-sized Qt Quick application startup is 30-40% faster with compiled Qt Quick. This is an excellent improvement and we believe we can improve this even more in the future. The highest startup time improvements we’ve gotten are as high as 90% in the case where the application is very JavaScript intense and contains no other items, like graphics, to load at startup.

Qt Quick Compiler is also very beneficial for keeping your source code safe, as it is now no longer necessary to ship the sources of your QML-based application. This makes Qt Quick to be on par with IP protection compared to C++, which is greatly appreciated in many industries.

Qt Creator 3.1.2

The installer packages also include Qt Creator 3.1.2, which provides a set of bug fixes and improvements, for example:

  • Fix of a crash in editing with highlight definitions and indentation based folding enabled (QTCREATORBUG-12172)
  • Fix of a GDB crash with large object names (QTCREATORBUG-12330)
  • Fixed filtering in help topic chooser

For full list of changes, please check the Creator 3.1.2 change log.

Charts and Data Visualization

Today we have also released the Qt Enterprise Data Visualization 1.1 and Charts 1.4 add-ons. Both of these contain improvements and new features based on customer requests, for example custom 3D objects and labels can now be drawn in graphs, axis labels are now interactive, and logarithmic axis is now supported also for Data Visualization (as has already been with Charts).

Check the Blog post for more details about Qt Enterprise Data Visualization 1.1 and Charts 1.4 add-ons.

Get Qt 5.3.1 

Qt 5.3.1 is now tagged in the Qt Project repository and available via both online and offline installers. If you do not have the Qt 5 online installer or wish to use the offline packages, please Visit Your Qt Account, if you are a Qt Enterprise customer, or download the open-source installers from Qt Project downloads page.

If you would like to try Qt Enterprise, please Download the free Qt Enterprise 30 day trial.

Qt Data Visualization 1.1 and Charts 1.4 released


We’re happy to announce that we have now released the Qt Enterprise Data Visualization 1.1 and Charts 1.4 add-ons. Both of these contain improvements and new features based on customer requests.

DataVisualization_1_1

Data Visualization new features & functionality

  • Custom 3D objects and labels can be drawn in graphs to draw attention to certain areas or illustrate data relation to physical objects
  • Axis labels can be used to interact with the graph. For example, data scrolling can be implemented with dragging of axis labels
  • Graph aspect ratio can be defined
  • Logarithmic axis is supported
  • Graph can be rendered to an image
  • Axis titles have been added
  • Axis labels can be defined to automatically orient themselves towards the camera so that labels are easier to read from different angles
  • Graph can be drawn with orthographic projection
  • Possibility to select different graph elements (axis labels and custom items) has been added
  • Regular expressions can be used to split data between rows and columns in item model data proxies (e.g. splitting time and date from time stamps)
  • Sum and average functions have been also added for handling multiple matching values in item models

Performance

One of the most frequently asked questions related to Data Visualization has been how much data points can you draw. Of course the answer to this question depends heavily on the use case and level of Hardware Acceleration and OpenGL drivers. We have made several optimizations to facilitate different use cases, especially those with larger data sets. Performance optimizations include:

  • Optimizations to data caching when only a part of the data changes.
  • Introducing new experimental optimization hint: QAbstract3DGraph::OptimizationStatic for Scatter graph. Using this optimization flag causes the entire data set be treated as a single object, significantly improving rendering speed. It is ideal for large non-changing scatter graphs.

We have also changed the way drawing speed measurement is enabled to make it easier to test the performance. Drawing speed can be now measured by simply enabling QAbstract3DGraph::measureFps property.  Also please see Qt Weekly blog post: Qt Data Visualization tips & tricks for details about performance optimization.

For details of the functionality and usage examples please refer to the product documentation available at http://doc.qt.digia.com/QtDataVisualization

Charts improvements

Charts 1.4.0 release is mainly a quality improvement release containing 24 changes in total.

New features include:

  • Series values of the bars and line series points can be now shown on top of the bar and point
  • An image can be now used in drawing the scatter points also from QML Charts API
  • Category axis clear function can be also used from QML API

For detailed list of changes please see the README file included in the source package of Qt Charts. Charts documentation is available at http://doc.qt.digia.com/QtCharts

 

Both Data Visualization and Charts are included in the Qt Enterprise license, so they are free to use by all our licensees. You can test out the Data Visualization and Charts by downloading a 30-day free evaluationQt Enterprise customers can download binaries and source code through the Package Manager in Maintenance Tool or the Online installer. Modules can be found under Qt Enterprise Add-Ons in the package manager. Source packages are also available in Qt Account Downloads.

As always, the Qt Data Visualization and Charts are fully covered by our standard support. If you have any issues using them or want to share ideas for further development, just contact our support team through the Qt Account Support Center. 

Qt Weekly #14 Testing Accessibility on OS X


When talking about accessibility, the question of how blind people interact with computers often comes up. This article will explain the basics and take OS X as an example to let you test an application. There are many tools to help people with low vision, for example magnifiers. Here it helps a lot when applications provide sufficient contrast and use clear fonts. But magnification can only get you so far, and at some point it’s not enough to effectively use a computer anymore. This is where screen readers come into the picture.

A screen reader is an application that presents the screen contents to the user in a non-visual way, either using speech output or using braille displays. For testing it is usually enough to deal with the speech output of the screen reader, braille will usually work if speech works. OS X comes with VoiceOver out of the box which makes testing applications easy. For a full description of VoiceOver, head over to the documentation, we’ll just mention the most essential keyboard shortcuts here. There is also a tutorial for VoiceOver that is a fun way to get started. To test a Qt application just run the application and turn on VoiceOver (Command-F5). For OS X, accessibility support in Qt has improved a lot lately, so make sure to use Qt 5.3 at least.

As an example application for this post we use the text editor example that ships with Qt (examples/widgets/richtext/textedit). Here is a screenshot of the window:
Screenshot of TextEditor example

When moving the text cursor VoiceOver will read the current line when moving up and down and reads individual letters when moving the cursor left and right. For the screenshots an option to display what VoiceOver says graphically was enabled, this is also helpful while testing.
Screenshot of TextEditor example with VoiceOver running

To move around and explore the window VoiceOver has some shortcuts that control a virtual focus. The focus is visualized with the black rectangle to help sighted people understand what is going on. Pressing Control-Alt-Left or -Right moves the VoiceOver cursor from one widget to the next. This is a good way to test that all UI elements show up and have sensible labels. Take for example the tool bar. The buttons have icons only and yet they should convey their meaning when read with the screen reader. Here is an example of VoiceOver reading the save button:
Voice Over reading the save button

If you encounter unlabeled widgets that is usually easy to fix by calling QWidget::setAccessibleName() with the right string or using Qt Designer to type in the text as property. The name has to be a short title for the widget (such as “Save”). It conveys the same information that the widget’s icon gives for example. Screen readers will know that it’s a button and add that information. When additional hints are needed, accessibleDescription should be set just like name, this information will be used as additional hint that is usually read after announcing the element (such as “Saves the current document”).

There are still many things to consider, but following best practices and conventions when designing applications often gets most of the work done. Then some manual testing should follow and finally user feedback needs to be taken into account. For complex custom QWidgets it is necessary to write sub-classes of QAccessibleInterface, which is material for another post. For Qt Quick there is the Accessible attached property. It’s documentation will be improved in Qt 5.4, thus the link to a doc snapshot. The Qt Quick Controls come with good preset properties so that most things just work, similar to QWidget. Sometimes it is still necessary to tweak a few things or to add accessibility for custom controls.

Testing on other platforms and the details such as writing custom QAccessibleInterfaces will be discussed in later posts.

Context-sensitive CMake documentation in QtCreator

CMake 3.0 was released last week with many major new features and new Qt integration for uic and rcc. A major change with this CMake release is the new documentation system based on reStructuredText and Sphinx.

Sphinx has the ability to generate Qt Assistant files, so these are now easy to create reproducibly from the CMake source documentation. Generated qch documentation for CMake 3.0.0 is available here. Load it in QtCreator through the “Tools -> Options” menu item.

Of course, when the documentation is easily available in QtCreator, the next step is to access it while editing your CMake files. A simple patch to QtCreator will allow navigating to CMake documentation by clicking a command and pressing F1 as usual.

creator

The post Context-sensitive CMake documentation in QtCreator appeared first on KDAB.

Playing with QV4

QtDeclarative is where the fun is. Starting with Qt5.2 a JavaScript Engine written by Digia is used. Compared to JavaScriptCore and V8 this engine is very basic but tightly integrated with the QML and Quick code. Motivated by attending the Qt Developer Summit and my work on GNU Smalltalk I started to look at the VM.

There are some environment variables that help to see what the JavaScript VM is doing and also how it is doing things. The below table gives a quick overview of the available flags and what they do. Specially the usage of QV4_SHOW_IR and QV4_SHOW_ASM helps to understand what is going on.

Name Function
QV4_NO_SSA Do not convert the IR::Function to SSA representation. This disables optimizations as well.
QV4_NO_OPT Do not run the optimizer. This disables dead-code-elimination, constant propagation, copy propagation
QV4_SHOW_IR Show the Intermediate Representation at the various stages of the compilation/optimization.
QV4_SHOW_ASM Show the disassembled code. This requires QtDeclrative to be compiled with CONFIG+=disassembler and without PCH
QV4_NO_REGALLOC Do not use the linear register allocator
QV4_FORCE_INTERPRETER Do not use the JIT but force the interpreter
QV4_MM_AGGRESSIVE_GC Run the GC on every allocation
QV4_MM_STATS Print the time it took to mark and sweep

DevDays Europe Now Live!

The Qt Developer Days 2014 website is now live!

Registration for Qt Developer Days Europe (Oct 6 – 8 Berlin) is now open. Register before midnight on July 18th and qualify for the Early Bird Prize Draw.
Also, the Training Day program is now available, choose from ten possible trainings!

The Call for Papers is out now – Submit your paper and share your knowledge of Qt during the 2 day conference session after the training day!
Maybe you know about Qt on iOS, or you have some product development stories or Qt case studies you’d like to share, or you’d like to offer a tutorial, or a talk on user experience and design guidelines. Let us know! Chosen contributors get in on Oct 7 – 8 FREE for helping this flagship annual event to reach its impeccable standards.

 

 

The post DevDays Europe Now Live! appeared first on KDAB.

Qt Weekly #13: QStringLiteral


QStringLiteral is a macro that allows you to create QString objects from string literals with little to no runtime overhead. However, its usage can be tricky especially in code that must compile with different compilers, like the Qt code itself. This blog post lists some guidelines to help you avoid the pitfalls.

QString is the ubiquitous representation for a Unicode string in Qt. A common source for a QString are literals hard-coded into the application. In Qt 4, any such creation of a QString from a literal required creating the QString object on the heap, and then translating the literal characters from its run-time character codec to UTF-16. Since Qt 5.0, QStringLiteral allows to avoid this overhead by creating the object and doing the conversion at compile time.

Enable C++11 in your project

QStringLiteral is only optimized if the C++ compiler both supports lambdas and unicode literals. This is the case for Microsoft Visual Studio 2010 and newer, but GCC and Clang need to be told that they should support all C++11 features. When using qmake, this can be achieved by


CONFIG += c++11

Without the features, QStringLiteral falls back to QString::fromUtf8().

Use QStringLiteral only if a QString needs to be created

This sounds trivial, but it’s not necessarily so. Some methods in the Qt API have overloads for either taking a QString, or a QLatin1String object. This is because Latin1 is simpler to parse than UTF-16, and therefore the QLatin1String version can be faster, and use less memory. This is worth remembering especially for some QString methods:


bool same = (str == QLatin1String("Hello"));
str.startsWith(QLatin1String("Hello"));
str += QLatin1String("World");

are more efficient than


bool same = (str == QStringLiteral("Hello"));
str.startsWith(QStringLiteral("Hello"));
str += QStringLiteral("World");

Do not use QStringLiteral for empty strings

Prefer


QString()

over


QStringLiteral("")

The default constructor for QString is cheaper in terms of both instructions and memory.

Avoid duplicated QStringLiterals

Avoid having multiple QStringLiterals with the same content. For plain literals and QLatin1String, compilers try to consolidate identical literals so that they are not duplicated. For QStringLiteral, identical strings cannot be merged.

String concatenation

Unfortunately Visual Studio does not implement concatenation for string literals in the way the C++11 standard says. That is, having multiple adjacent “ ” sections (e.g. useful to spread across multiple lines) won’t work:


// error C2308: concatenating mismatched strings
// Concatenating wide "Hello" with narrow "World"
QStringLiteral("Hello " "World");

Other Visual Studio bugs

There are also other bugs in older Visual Studio versions. Here are a few known ones:


// (Visual Studio 2010, 2012)
// error: C1001: An internal error has occurred in the compiler.
QString array[2] = { QStringLiteral("Hello"), QStringLiteral("World") };


// (Visual Studio 2010)
// C2587: 'holder' : illegal use of local variable as default parameter
static QString formattedAddress(const QString &address,
        const QString &newLine = QStringLiteral(""))
{
  // ...
}

Summary

QStringLiteral speeds up the creation of QStrings from literals, at the expense of bigger binary sizes. To make these optimizations it requires C++11 features. There are cases though where using QStringLiteral does not pay off: For Qt API that optionally takes a QLatin1String, and for empty strings.

If you use QStringLiteral you should avoid declaring the same literal in multiple places: This furthermore blows up the binary sizes. Also, QStringLiteral exposes some bugs in Visual Studio compilers.

Further reading

Olivier Goffart explains both the reasons and the implementation of QStringLiteral in his highly recommended QStringLiteral blog post. Thiago Macieira blogged about it too.