Mitch Curtis

Qt Quick Controls Re-engineered – Status Update

Published Monday November 23rd, 2015
56 Comments on Qt Quick Controls Re-engineered – Status Update
Posted in Dev Loop, Performance, Qt, Qt Quick, Qt Quick Controls

Since announcing research on Qt Quick Controls optimized for embedded use, we’ve made good progress towards achieving feature parity with the original Qt Quick Controls. We’ve also added some new controls that didn’t exist (Drawer, RangeSlider, and SwipeView, to name a few).

The previous blog post cited performance reasons as the motivation for having one fixed style. However, we have found a way to make multiple styles available without sacrificing performance. So far, two new styles have been merged, implementing both Google’s Material Design and Microsoft’s Universal Design.

 

material

Material style

universal

Universal style

It’s important to note that these styles are not claiming to be native, but instead a 100% cross-platform implementation of the Material and Universal design guidelines. For example, the Material style does not adapt to any Sony or Samsung theme on Android. You can run these styles on any platform and they will look more or less identical.

We’re also working on a neutral, optimised base style, and a fancier “Qt” style, both in cooperation with our designers.

Earlier, we talked about separating the C++ logic and the visual QML layer. Thanks to the feedback from our users, we have realized the power of a pure C++ logic layer and have decided to expose it separately for those wanting to build their own custom user experience. We’ve named this layer “templates”. A template is the foundation of a control. They encapsulate the behaviour of controls and provide an interface for styles to do their thing, allowing a true separation of concerns. For an introduction to this concept, take a look at the following video taken from the 2015 Qt World Summit:

The styling system now uses a technique similar to file selectors to choose which style to load at application startup. There are currently two ways to choose the application style:

  • An environment variable:
    QT_LABS_CONTROLS_STYLE=universal
  • The “-style” application argument:
    -style material

A manifest file for specifying the preferred style and style-specific attributes is also being considered as a future addition.

The more complex beasts like TableView and TreeView are on our to-do list. We realise that these are some of the most important controls, remaining quite relevant even on touch devices. Given the great opportunity that we have (to completely redesign all of the controls), we’d like to take the time to design these particular controls to be as lean as possible. After all, they are typically showing the most data. Not using Loaders has already given us a substantial head start in this area.

Popups are also getting some love, with a new approach that uses Qt Quick items instead of native top-level windows. What this means is that:

  • All platforms will have full access to menus, even embedded systems that don’t support multiple top-level windows.
  • Controls like ComboBox will be fully styleable, which was not possible with native windows in Qt Quick Controls.
  • Internal focus and key event handling is simplified.
  • It is easier to auto test things like menus, resulting in greater test coverage.
  • Popups will be bound to the window in which they were created.

Controls that will take advantage of this approach include Menu, ComboBox and PieMenu, with ToolTip also being considered as a new addition.

Finally, with the new infrastructure, we’ve decided to consolidate some of the controls from Qt Quick Extras into the module, resulting in one less import to remember. Not all of the controls made the cut, as we’d like to get an idea of which of these are in demand so that we can focus on the core areas of the module. Creating suggestions on our bug tracker (under the component “QtQuick: Controls 2“) is a great way to let us know what you’d like to see as part of the offering.

Here’s a small example of a Qt Labs Controls application:

import Qt.labs.controls 1.0

ApplicationWindow {
    visible: true

    Button {
        text: "Hello World!"
    }
}

We will be releasing a technical preview of the new controls in Qt 5.6 (with the working title of Qt Labs Controls), with a proper release planned for 5.7. We’ve had some early adopters trying out what we have so far, and giving us feedback via the bug tracker, which is great! If you’d like to do the same, try out the latest Qt 5.6 snapshot.

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

Posted in Dev Loop, Performance, Qt, Qt Quick, Qt Quick Controls

56 comments

Will Stokes says:

Can we get a status update regarding native iOS controls? I’m sure I’m not the only one anxiously awaiting native controls across mobile platforms.

Mitch Curtis Mitch Curtis says:

Native controls are not within the scope of this module. However, there is interest/discussion around this within the Qt community:

http://lists.qt-project.org/pipermail/development/2015-April/021035.html

Marco Piccolino Marco Piccolino says:

+1 about support for iOS controls.

I take the occasion to point to the following existing projects until the new control styles will be available:
https://github.com/papyros/qml-material
https://github.com/benlau/quickios
https://github.com/benlau/quickandroid

QML Material is a very extensive library and also includes support for Material-specific concepts, such as elevation

Nikita Krupenko says:

I think, it should be possible to add an iOS style. And hope, it’s in priority list, as adding this style will open ability to create native-looking applications for three major platforms with less effort.

Alessandro says:

We set our QApplication style by using a single qss. Now we are inserting some Qt Quick Controls inside our widgets. Is it possible to customize Qt Quick Controls by using a QStyle Sheet?

J-P Nurmi J-P Nurmi says:

Hi, neither the original nor the re-engineered controls support widget-based style sheets. Both control sets are stylable and customizable to a great extent, but the presentation language used for that is QML.

Alessandro says:

So, in a Qt Application in witch coexist Qt Widgets and Qt Quick Controls the style must be set by using both .qss and .qml file. Is not possible to set the style in a single point! Do you confirm?

Thanks ?

J-P Nurmi J-P Nurmi says:

I can confirm that it’s not possible to use QSS in QML or vice versa. They are two different UI technologies. The most optimal solution would be to avoid mixing the two, but I understand well that this is of course not always feasible. 🙂

Alessandro says:

Our Desktop applications uses:

– QWidget-based API (e.g., Qwt, Qwt Polar, QGis)
– QtQuick controls for touch interaction

Qt Creator is another example of an application that mixes different UI technologies.

In my opinion, nowadays, for complex Desktop applications the standard is to mix and match different UI technologies.

Why do you think that it is better to avoid mixing the two approach?

Are you thinking to find a unique way to set the style both to QML and QWidget UIs?

Thanks ?

J-P Nurmi J-P Nurmi says:

With most optimal I literally mean the most optimal. 😉 Having a bridge between the two worlds is hugely important for Qt, but crossing the bridge comes at a little expense. For more details, check the detailed description part in the QQuickWidget documentation.

ekke ekke says:

will I be able to test and run these new controls on Android from 5.6 ?

Mitch Curtis Mitch Curtis says:

Yep! They should work on all platforms supported by Qt, although the 5.6 release of the controls will be a tech preview, as previously mentioned. Please report any bugs you find. 🙂

ekke ekke says:

great to hear this. as soon as 5.6 beta is available I’ll start testing this for Android.
Coming from Qt 4.8 / Cascades / BlackBerry10 looking for the best way to develop for BlackBerry Android Devices and re-using parts of my app (C++ business logic)
also good to see that you’re now using C++ for new Controls. (Cascades always did this)
Will blog about my experiences.

Gunnar Roth says:

you wrote ” Not using Loaders has already given us a substantial head start in this area.”
could you give more details? Normally Loaders are meant to speed things up, now you say the opposite.

Mitch Curtis Mitch Curtis says:

In general, Loaders are good when lazily loading larger items (e.g. pages) at the application level, and in this sense, they are perfect for application developers. However, the original Qt Quick Controls use multiple Loaders for each control to be able to dynamically choose between different style implementations. This introduces significant runtime overhead that we have entirely eliminated in the new set of controls.

Ben says:

Very excited to start using these new controls.

Mitch Curtis Mitch Curtis says:

Great to hear! Do you mind me asking what kind of devices you’re targeting?

TTG says:

THIS IS GREAT!!! Please keep polishing the controls, make the light fast and elegant. And could you provide some guide for customizing styles? I have a lot nice UI kits. Thank you.

Mitch Curtis Mitch Curtis says:

Thanks! 🙂 Here is a guide for customizing each control:

https://doc-snapshots.qt.io/qt5-5.6/qtlabscontrols-customize.html

Is that what you were after?

Seelook says:

There are awesome news….
Is there any chance that QtWidgets will have such toys? Or QtWidgets in mobile world are rather obsolete?
I almost ported complex QtWidgets to Android and there were many questions to resolve (some are still there).
Bunch of such controls may make live easier…..

Anyway, thank You a lot for your work!

Arthur Turrini says:

Me too. I’m using QtWidgets on Android with QSS, right scaling and everything else.. It just works. Even animations and touch interface.

It’s nice to see that QML is getting up par with Qt Widgets, but I’m worried about memory & cpu consumption

bacarozzo says:

Hi Mitch,

thanks for the nice update and for your hard work on this. The controls looks very nice in the universal style. I will have a look to the source code to steel some genuine ideas. 🙂

Mitch Curtis Mitch Curtis says:

Thanks! We appreciate it! JP is the mastermind behind the new controls (and he implemented the Universal style), so all credit goes to him. :p

And yes, please do take inspiration from the code!

bacarozzo says:

Well, also the Android theme looks nice. The thing is I’ve already implemented (most of) that for the original quick controls and I’m more interested in “taking inspiration” for the other one. 😛

That said, I’m curious to see the Android theme implementation also, especially the ink effect. I’ve (a little bit) reworked the approach used here and I’m curious to see the implementation in controls 2. I should admit I’m a little lost while browsing git. Could you please provide a direct link to the relevant git files?
Thanks a lot.

Mitch Curtis Mitch Curtis says:

The material style implementation is here:

http://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/imports/controls/material?h=5.6

Note that, as with a lot of the module, it’s still undergoing development. There are only basic animations for the time being; no ripple effect yet. 🙂

bacarozzo says:

Ah perfect! Thank you so much. I don’t know how I could have missed that folder. Definitely looking inside it.

I know they are under development. Still, they are really promising and it really seems to me that they are the right step toward correct/full support of mobile platforms. Keep up the good work! 🙂

Marco Piccolino Marco Piccolino says:

@bacarozzo, for an Ink implementation in QML you can check this out: https://github.com/papyros/qml-material/blob/develop/modules/Material/Ink.qml

BaCaRoZzo says:

Thanks Marco but I’ve already implemented the ink effect, as said above. Look at the link in the previous message for the implementation I’ve used as a reference.

I was just curious about how they could have implemented inside the new controls module.

I think the solution based on ShaderEffect is more elegant, easier to maintain and looks cooler. 🙂

Marco Piccolino Marco Piccolino says:

All right, I definitely misread that bit. Having these different implementations will definitely be beneficial for the whole progress.

Marco Martin says:

Any plans for desktop related styles?

Mitch Curtis Mitch Curtis says:

Could you elaborate on this? The Universal and Material designs were developed to be platform-agnostic.

Marco Martin says:

To be fully usable on a desktop, on a functional level they would need to have better keyboard navigation, shortcuts support and things like popup menus actually in different windows.
On the look side, to look decently integrated with the other applications in the desktop, it would need to have a theme that integrates well (it may mean painting with QStyle, like qtquiccontrols 1 that has problems on its own)
but yeah, a material look on for instance a mac or a linux desktop will work, but would look a bit alien and possibly they would work better for a touch screen input method rather than mouse+keyboard

J-P Nurmi J-P Nurmi says:

Hi Marco. Thank you for your insights. Let me try to shed some light on the choices we’ve made.

When the original project, Qt Desktop Components, was born, Qt Quick was still at version one. It was based on the Graphics View framework and QPainter. From technical point of view, integration with QStyle made a lot more sense than it does with Qt Quick 2 and its OpenGL-based scene graph. It was clear from the beginning that we would no longer want to integrate with QStyle.

Qt Quick was designed for building stunning, fluid, animated user experiences. It was never meant to be a toolkit for emulating the native experience of varying platforms ranging from mobile to desktop. For me, the Android style was an eye-opener in many ways. First of all, no matter how well you replicate the looks, the feel is off. Secondly, giving the native promise leads to ever-growing complexity. The leading platforms are developing at crazy pace these days. They are releasing new major versions every year, and competing hard at innovating new ideas to differentiate from each other. It wouldn’t take long until we would be back to the starting point – performance problems due to complexity. This project was specifically born to demonstrate how amazing performance we can achieve if we keep things simple and don’t give the native promise.

Marco Martin says:

> When the original project, Qt Desktop Components, was born, Qt Quick was still at version one. It was based on the Graphics View framework and QPainter.

Well, i know the story.. As the maintainer of the QtQuick based controls used in the Plasma desktop, we always tried to keep up.. and frankly has been a bit frustrating at times since I lost the count of how many rewrites we went trough, as the next big change in qtquickcontrols was always “this is the one!” (there is still code derived from the Symbian S60 components API, that was one of the first that got public…)

Now, we do have interest in mobile applications as well, and such components are looking indeed great for it!
But for the use in desktop applications always looks like something is missing, in look and functionality (note for instance under Windows where classic applications keep being overwhelmingly more popular than metro apps: there seems to be in place a dichotomy between pretty on one side and useful/powerful on the other that shouldn’t be there at all)

Since now also QtQuickControls2 appears to be themable, if you guys are not interested in a desktop specific theme, we can maintain one: being “a bit off” and have some qpainter-induced inefficiencies for us is better than having no integration at all, that makes it pretty much a roadblock in implementing major desktop applications in.
Just a theme is probably easy, what will probably be more tricky is controls that we will need on the desktop that won’t be needed on mobile (like menubars, spinboxes, maybe comboboxes) that would mean we either maintain our separate sub-components set or stick with qtquickcontrols1 for the required objects.

J-P Nurmi J-P Nurmi says:

> Now, we do have interest in mobile applications as well, and such components are looking indeed great for it!

The boundaries between desktop, mobile, and embedded have become fuzzy. UIs that have been designed primarily for touch and keypad navigation _can_ also work fine in a traditional desktop environment with mouse pointer and all that. It doesn’t work the other way around. Qt Quick Controls 1 are a living example of that.

> But for the use in desktop applications always looks like something is missing, in look and functionality (note for instance under Windows where classic applications keep being overwhelmingly more popular than metro apps: there seems to be in place a dichotomy between pretty on one side and useful/powerful on the other that shouldn’t be there at all)

Windows 8 was such a disaster that it made “Metro” sound like a swear word. The Universal Windows Platform aka Windows 10, however, is already a success. What makes it particularly interesting to us is that it has been designed for hardware acceleration. In other words, it’s a perfect match with Qt Quick.

> Since now also QtQuickControls2 appears to be themable, if you guys are not interested in a desktop specific theme, we can maintain one: being “a bit off” and have some qpainter-induced inefficiencies for us is better than having no integration at all, that makes it pretty much a roadblock in implementing major desktop applications in.

It’s not about “some inefficiencies”, it’s about what makes sense from technical perspective. A QStyle-driven animation renders every single frame on the CPU. Furthermore, QStyle paint results are blobs of random stuff – effectively crippling the scenegraph batch renderer. That’s more like software deceleration than hardware acceleration. Multiple top-level QQuickWindows nail the coffin by choking the render loop. Case closed. 🙂

QStyle worked great in the past. It solved perfectly the problem of painting different looking buttons in different states on different platforms. The concept broke the day animated UIs were invented. I wouldn’t base any new technology on QStyle.

> Just a theme is probably easy, what will probably be more tricky is controls that we will need on the desktop that won’t be needed on mobile (like menubars, spinboxes, maybe comboboxes) that would mean we either maintain our separate sub-components set or stick with qtquickcontrols1 for the required objects.

SpinBox we already have, but ComboBox is still in the works (non-editable version almost done).

Mitch Curtis Mitch Curtis says:

I’m curious about what kind of popups you’re talking about here, and why is it necessary to have them in separate windows?

Marco Martin says:

> I’m curious about what kind of popups you’re talking about here, and why is it necessary to have them in separate windows?

like menubars or right mouse button popup menus (pretty much anything QMenu does)

Their geometry can go outside or not fit the application window, especially in the case of child or grandchild menus

ekke ekke says:

Keyboard Navigation and Shortcut support is also important on mobile devices, where external keyboards are connected via Bluetooth or even integrated into the device like the new BlackBerry Android device (PRIV)

ekke ekke says:

cool. will try it out on Android with BlackBerry PRIV – will start development with 5.6 beta

stephane says:

Looks promising !
I love the idea of the new architecture !

Stephane says:

Hi,

Digging into documentations, I see there is no support for “hover” on desktop… Is it planned to add ?
Desktop button without hover is just… sad !

Thanks

J-P Nurmi J-P Nurmi says:

Hi Stephane. Hover-support is also on the todo-list.

Hamer says:

Hover support is also a must-have for me. I am developing a multi-platform application (mobile+desktop) which uses responsive qml so there is single code for all platforms and the new version 2 controls are looking great for this.

Hamer says:

I also hope that the controls will wort on Windows RT and Windows Phone devices (for instance the Flat style which is currently shipped with the QtExtras and QtEnterprise does not work on these systems).

J-P Nurmi J-P Nurmi says:

Hi. I haven’t had the chance to try it out myself, but I’ve witnessed the new controls running great on a Windows Phone. Everything worked nicely out of the box, even though we didn’t yet have the Universal style in place back then.

Nikita Krupenko says:

I use it already for for project I’m developing 🙂

I think it is a huge leap for creating interface for mobile devices with QML!

Are there any plans to re-implement Controls 1 on top of labs.templates?

J-P Nurmi J-P Nurmi says:

There have been such ideas floating around, but no immediate plans. We are moving fast and closing the biggest gaps soon, so it remains to be seen how much there is left to port besides the QStyle-integration which was intentionally left out (see the reply to Marco’s comment).

Ben Lau Ben Lau says:

Beside look and feel for Material designer. Will it also fix problem like copy/paste in mobile environment?

Reference:
https://bugreports.qt.io/browse/QTBUG-34867

J-P Nurmi J-P Nurmi says:

Hi Ben, we’re currently working on a solution to make text selection handles available via platform plugins (instead of building that into the editors itself like we did in controls 1). There are similar ideas for select/cut/copy/paste -functionality, which is essential for text editing on mobile.

Ben Lau Ben Lau says:

Great to know that. Any reference design /discussion we could know how will it be implemented?

Scorp1us says:

Will this eliminate the start-up flicker on Android? Currently if you use a drawable in the manifest, any use of Controls (but particularly TextField) results in a black flash and significantly increased startup time. This does not happen on iOS. This also does not happen with the unstylable TextInput

J-P Nurmi J-P Nurmi says:

Our TextField is currently no more than TextInput extended with placeholder text and background item. No wrapping, but direct inheritance. I’d be surprised if you got different results between the two.

Marco Martin says:

One thing I find missing in this new set is a replacement for the (non graphic, actually) component Action.

I find it very useful for representing conceptually generic actions the application can do, that then get repreented by the app how it wants, such as a button, a popup menu, a custom styled mousearea…

but perhaps in qtquickcontrols1 wasn’t really the best place for it: I was a bit disappointed back then when that class was recomended in place of QAction (that I know, dependency chain problem…)

The best way would be a class usable both directly by C++ (something new in qtcore if QAction really can’t be used?) and as a QML component, to make very easy for the application logic to expose collections of supported actions, that then the qml part can just represent them in a model/view fashion, like a popup menu, a menu in the sidebar or whatever.
Any plans on that regard?

J-P Nurmi J-P Nurmi says:

We have introduced Shortcut, a non-graphical replacement of Action in Qt Quick 2.5: http://doc.qt.io/qt-5/qml-qtquick-shortcut.html.

Ever since Action was introduced, we got frequent questions about “how to use different icons and labels for the same action in different contexts” and “how to know the source that triggered an action”. Both of these contradict the sole purpose of Action (which also stems from classic desktop UI paradigms), and neither “problem” would exist if they wrote simpler QML code in the first place, as illustrated by the following example snippets:


Action {
id: myAction
text: "Hello"
onTriggered: doSomething()
}

ToolBar {
ToolButton {
action: myAction
}
}

Menu {
MenuItem {
action: myAction
}
}

vs.

ToolBar {
ToolButton {
text: "Hello"
onClicked: doSomething()
}
}

Menu {
MenuItem {
text: "Hello"
onTriggered: doSomething()
}
}

Evidently the most useful part of Action is the shortcut feature, which is now available in QtQuick core.

EDIT: Sorry for the formatting, this blog doesn’t seem to like code snippets in comment fields.

Commenting closed.

Get started today with Qt Download now