Leena Miettinen

Qt Weekly #9: Creating Scalable Qt Quick Apps

Published Friday May 9th, 2014
8 Comments on Qt Weekly #9: Creating Scalable Qt Quick Apps
Posted in Declarative UI, Qt Quick 2

Qt Quick contains features that enable you to develop apps that can run on different types of devices, such as tablets and handsets. In particular, the apps can cope with different screen configurations: size, density, orientation, resolution, and aspect ratio.

A Qt Quick app run on different types of devices.

To implement scalable applications using Qt Quick:

  • Design UIs using Qt Quick Controls that provide a set of UI controls for creating application windows and their standard parts, such as a menu bar, tool bar, and a status bar. The size constraints of the content items are taken as input when calculating the effective size constraints of the actual window. Additional controls are provided for creating views and menus, as well as presenting or receiving input from users. You can use Qt Quick Controls Styles to apply custom styling to the predefined controls.
  • Define layouts using Qt Quick Layouts, which can resize their items. You can position screen controls in a row, column, or grid.
  • Use property binding to implement use cases not covered by the layouts. For example, to display alternative versions of images on screens with low and high pixel density or automatically rotate view contents according to the current screen orientation.
  • Load platform-specific assets using file selectors.
  • Load components on demand by using a Loader.

These features are described in more detail in Qt 5.3 documentation. We would now like to collect feedback from developers to find out how well the current features fit your needs and how we could improve them and the documentation. Please tell us about your experiences in developing scalable Qt Quick apps in the comments. If you have suggestions or feature requests, add them as subtasks of the Improve UI Scalability task (QTBUG-38858) in the Qt Bug Tracker. Also, keep reporting the bugs that you find and link them to the task.


Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Declarative UI, Qt Quick 2


The scalabality docs in Qt 5.3 are quite good already.

When learning the Qt 5 scalability featuers, I found the talk from Alan Alpert at Qt Dev Days 2013 the best overview. The link to his slides is here

Also his presentation is worth a look, available on Youtube here

For games and some apps, you often want the same UI and game experience on all devices (e.g. to allow comparable leaderboards). We have created a tutorial How to create mobile games for different screen sizes and resolutions on the V-Play site, available here: http://v-play.net/doc/vplay-different-screen-sizes/

With our approach, developers have the benefit of only defining the game for a single logical resolution which makes it faster…

DavidB says:

I started looking at using at using QtQuickControls for a desktop app, but the one thing that detered me was – ” You still have to count pixels”. I think you can get away with this in the embedded space, but on the desktop it goes against the philosophy of every major tool kit with layout mangers even QWidgets.

Corrrect me if I am wrong but I found that even to use a QML Layout like RowLayout I had to give it a height. With desktop screens ranging from VGA to Retina displays (ok VGA is a stretch now adays). I as a programmer don’t want to create 6 different QML interfaces, and then have to write my own layout adjustments with font changes, nor worry about what size to scale my svg icons to for a given resolution.

I am hopping for the day when QML can be resolution free just like its good old QT Widgets

Scorp1us says:

Generally, you don’t. And it is considered bad form to specify a hard-coded size. For the most part, things will select the correct size for themselves. And you can just nest in layouts appropriately. I would say that 90% if you want to use a pixel value, you don’t actually have to. There is usually another way of thinking about the problem. particularly what it is attached to.

Leo S says:

We are developing cross platform mobile apps with Qt and over the last year have settled on the following strategy for fonts and UI element sizes.

1. One singleton Visuals.qml file that defines sizes and fonts and colors. So it has things like:
property int mediumFontSize: 18 // font size in pixels
2. For each platform, we use QML file selectors to load an appropriate Visuals for the platform. Font sizes in pixels are set using the standards on the platform and the DPI. In the future we might implement a C++ backend to calculate dynamic font sizes to support technologies like iOS Dynamic Type.
3. Most UI prototyping happens on Windows because of the quick compile/test cycle. For each platform we calculate a scaleFactor which the ratio of the current DPI to a constant. This allows us to size elements on Windows, and then have them scale appropriately on other platforms. For example, in Visuals we have statements like:
property int buttonHeight: 28*scaleFactor

Leo S says:

Our first instinct was to set font sizes in points but that quickly broke down, since the theory that a fixes point size will be the same physical size across devices isn’t even remotely reflected in practice.

Scorp1us says:

That sounds right, but my compiles are faster under Linux. Also, a SSD will be very worth it.

Scorp1us says:

One area where Qt/QML beats the pants off Android SDK development is everything is a widget/component. There is no need to worry about “is it an Activity or a fragment?”, and the separate and intermingling lifecycles of each other. (OnCreate, OnCreateView, OnAcivityCreated, OnResume, OnStart, etc, along with Intents and Bundles)

Hooray for Qt!

Commenting closed.

Get started today with Qt Download now