J-P Nurmi

Are you ready for Qt Quick Controls 2.3?

Published Thursday November 23rd, 2017
25 Comments on Are you ready for Qt Quick Controls 2.3?
Posted in Dev Loop, Qt Quick 2, Qt Quick Controls, Styles, UI

This blog post takes a brief look at some of the new features in Qt Quick Controls 2.3 released as part of Qt 5.10. See also New Features in Qt 5.10 for a more detailed list.

New styles

We are introducing two new styles: Fusion and Imagine. The Fusion style looks familiar to those who have been using Qt Widgets. This is a QML-based implementation of the same design.

The Fusion style

The Fusion style

The Imagine style is based on configurable image assets, giving designers full control over how the style looks like. The style comes with a default set of image assets that have been exported from Sketch.

The Imagine style

The Imagine style

With the Imagine style it is possible to style the controls without a single line of code. There will be also examples for Illustrator and Photoshop. These designs are provided as starting points for those creating their own designs. See Qt Quick Controls 2: Imagine Style from Mitch for more details.

Menus and actions

Menus and friends have taken big steps forward. We have added new QML types called MenuBar, Action and ActionGroup, and Menu has gained support for sub-menus. It is now possible nest menus, as expected on desktop platforms. We also added support for mnemonics in menus and buttons.

MenuBar and cascading Menus

MenuBar and cascading Menus

The usage is identical to the earlier generation of Qt Quick Controls:

import QtQuick 2.10
import QtQuick.Controls 2.3

ApplicationWindow {
    id: window
    width: 500
    height: 400
    visible: true

    menuBar: MenuBar {
        Menu {
            title: qsTr("&File")
            Action { text: qsTr("&New...") }
            Action { text: qsTr("&Open...") }
            Action { text: qsTr("&Save") }
            Action { text: qsTr("Save &As...") }
            MenuSeparator { }
            Action { text: qsTr("&Quit") }
        }
        Menu {
            title: qsTr("&Edit")
            Action { text: qsTr("Cu&t") }
            Action { text: qsTr("&Copy") }
            Action { text: qsTr("&Paste") }
            MenuSeparator { }
            Menu {
                title: qsTr("&Find/Replace")
                Action { text: qsTr("Find &Next") }
                Action { text: qsTr("Find &Previous") }
                Action { text: qsTr("&Replace...") }
            }
        }
        Menu {
            title: qsTr("&Help")
            Action { text: qsTr("&About") }
        }
    }
}

These are important steps bringing Qt Quick Controls 2 menus functionality-wise on par with native platform menus. This makes it feasible to start considering the next steps integrating native platform menus as a backend for Qt Quick Controls 2 menus.

Palettes

We have added support for configurable palettes, currently supported by the Default, Fusion, and Imagine styles. The other styles are coming later. Here’s a screenshot of the Default style with a custom dark palette:

The Default style with a custom dark palette

The Default style with a custom dark palette

Q & A:

What about TableView?
– We have made great progress with a new TableView based on the same Qt Quick item view framework ListView and GridView are based on. The current implementation is already able to manage a two-dimensional set of visible items for the current viewport. The performance is on the same level with ListView and GridView. Large amount of columns does not kill the performance like in the ListView-based TableView in Qt Quick Controls 1. Stay tuned for a blog post on the subject.

When is the famous “Object destroyed during incubation” problem going to be fixed?
– We believe we have now the necessary ingredients for finally tackling this issue. I have prepared a patch to the QML engine that allows us to defer the execution of the built-in delegates so that a) replacing them with custom delegates at construction time won’t cause troubles for asynchronous incubation and b) the performance (in terms of construction time) of a customized control is not affected by the built-in delegates. As soon as the necessary patch to the QML engine has landed, we can start making use of it in Qt Quick Controls 2. We are targeting the 5.9.x LTS series. I’ll report status updates to QTBUG-50992.

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

Posted in Dev Loop, Qt Quick 2, Qt Quick Controls, Styles, UI

25 comments

August says:

Will there be a repository with current version of TableView?

J-P Nurmi J-P Nurmi says:

Hmm, it used to be developed in public in the wip/itemviews branch in qtdeclarative, but I’m not sure where the latest changes are. I’ll get back to you as soon as I know more. ๐Ÿ™‚

Jakub Narolewski says:

Awesome :] QCC2 getting better and better with each new release.

Marco Piccolino Marco Piccolino says:

Thank you for the great write-up and the wealth of new features!

Nikita Krupenko says:

Nice work! Are there any plans to add something like the private component TreeModelAdaptor from QQC1?

J-P Nurmi J-P Nurmi says:

Yes, I think https://bugreports.qt.io/browse/QTBUG-54390 is a great idea. TreeModelAdaptor could be productized and moved to QtQml.Models, so one can use tree models with ListView and the upcoming TableView. I also mentioned it when the wip/itemviews branch was requested: http://lists.qt-project.org/pipermail/development/2017-January/028344.html ๐Ÿ˜‰

Gil says:

Are there any known shortcomings or gotchas with the new Menus or their integration on any of the desktop platforms?

J-P Nurmi J-P Nurmi says:

What do you mean? They are not yet integrated to the platform menus, that is just considered as a next step.

Gil says:

So, my understanding of “not integrated with the platform menus” is that on Mac, they don’t integrate into the menu at the top of the screen but rather, appear as part of the application window frame. Is that right? Any noticeable difference on Windows, where the menus are expected to be part of the window frame?

J-P Nurmi J-P Nurmi says:

Yeah, since Qt Quick Controls 1 was originally developed for desktop platforms, and therefore ended up having massive problems on mobile and embedded (*), we took a different route with Qt Quick Controls 2 and in the beginning focused strongly on that segment of customers that Qt Quick Controls 1 is unable to serve. So far we have been pretty successful at making touch/mobile/embedded -first things desktop-compatible later on. Going the other way around is much harder.

Anyway, given the focus in the beginning, we put our efforts into implementing an Item-based popup framework so that we were able to provide popups on embedded. Some desktop-oriented things, such as cascading sub-menus, haven’t been available until now. We did realize the big gap between our offering and the traditional desktop menus and menubars, so in Qt 5.8 we actually added an experimental API that provided native menus and menubars on those platforms that have them available (https://blog.qt.io/blog/2016/10/06/qt-quick-controls-2-1-and-beyond/). Unfortunately it was a no-go to use these as an optional backend before our menu offering in Qt Quick Controls 2 was on a level that makes the backend usable. In Qt 5.10, a native menubar is available (via Qt.labs.platform) for macOS, Windows, and some Linux desktops. The Qt Quick Controls 2 MenuBar follows the Universal design, so it looks like UWP not like Win32.

(*) Qt Quick Controls 1 menus and popups are top-level windows, which doesn’t work on platforms that support one top-level window. E.g. on embedded you would get no menus at all.

Louis says:

A few questions about all this:

* What is the current status of the support of QQuickWidget? Currently we have multiple things that are broken with QQuickWidget but that are working with QQmlApplicationViewer, such as Animators (QTBUG-62874) or also the fact that Shortcuts don’t work in WindowShortcut mode (QTBUG-62990).
* A suggestion about Qt.callLater(callback): what do you think about having another signature, Qt.callLater(callback, object) that allows to pass an instance (Item/QtObject/other) to cancel the call automatically when the object is destroyed? It would be very useful because we currently have to instantiate singleshot Timers with a delay of 0 to “queue” an event, for example. I don’t know if it makes sense ๐Ÿ™‚
* Looks like you thought about us with the Q&A! Do you plan to give more information about what is the “HeaderView” of http://lists.qt-project.org/pipermail/development/2017-January/028344.html? Is it related to the fact to be able to have groups of headers in TableViews?

Thanks for your work and information!
Louis

J-P Nurmi J-P Nurmi says:

* I don’t have a fix for QTBUG-62874 yet, but I have raised the priority to get it fixed as soon as possible. Looks like QTBUG-62990 got already fixed by https://codereview.qt-project.org/#/c/211675/
* Please report the Qt.callLater suggestion to Jira. It is implemented in the QML engine, not in Qt Quick Controls. ๐Ÿ˜‰
* The idea was to offer similar functionality to QHeaderView in Qt Widgets. Something that can be used as a header for TableView and TreeView, and can manage column sizes etc.

Louis says:

I created QTBUG-64737 as you advised. Thank you for the information and for QTBUG-62874 priority change!

J-P Nurmi J-P Nurmi says:

Thanks! Right now we have full focus on the โ€œObject destroyed during incubationโ€ issue, but fixing busy indicators in qquickwidget comes next.

Petya Kolbaskin says:

Your progress in QQ2 development is great, but it still does not behave as the desktop UI should, and not suitable as a replacement of QQ1 for me.
I just downloaded Qt5.10beta, run examples and found the following drawbacks:
* Rubberband scrolling, which is good for mobiles but not for the desktop
* No mouse selection and the context menu in TextField
* Dialogs don’t have a close button, they are not moved by the mouse and are limited by the parent window
* Menus don’t display shortcuts
* There is no convenient way to specify ToolButtons tooltips (Action.tooltip in QQ1)

Jakub Narolewski says:

QQC2’s TextField inherits TextInput directly from QtQuick 2.X import. You can set selectByMouse to true to get mouse selection. Context menu is easily implementable with Menu item. This is how I did it :]

Petya Kolbaskin says:

My fault, I did not notice that selectByMouse disabled. But should not it be enabled by default? The same with the context menu, in 99% of cases it is needed.
I think it’s not great that Qt shifts the implementation of the basic functionality to the user. Any GUI framework known to me (including QtWidgets and QQ1) has the TextField context menu, but not QQ2.

J-P Nurmi J-P Nurmi says:

You are 110% right that it should just work. Personally, I think selectByMouse should not even exist. It’s basically a workaround for the fact that many things in Qt Quick core do still not handle proper touch events, but rely on synthesized mouse events. Because of this, flicking on touch and text selection by mouse drag conflict, so this property was added to mitigate the problem. The way it would ideally work is that a developer simply defines the desired selection mode (no selection vs. select chars vs. select words) and the platform specific input methods handle it so that on touch, selection is triggered by a long press, not by a “mouse drag” synthesized from touch events. That way, flicking an editor on touch would not conflict with text selection by mouse drag.

J-P Nurmi J-P Nurmi says:

Thanks for the constructive feedback! We’re constantly looking for ways to improve QQC2 on desktop. At the same time we’re trying to be extra cautious to avoid the pitfalls known from QQC1. Things like native menus, tooltips, and window-backed popups are on the radar.

Petya Kolbaskin says:

I have no plans to use QQ2 on mobiles, but I checked out how text selection works on Android 6. It looks and behaves differently from the native. In addition, it is full of bugs:
The text selection handles do not correspond to the position of the text.
The text is not scrolled while the handle dragging.
The selection mode does not stop when the Back button is pressed.

I’m somewhat disappointed in Qt. ๐Ÿ™

J-P Nurmi J-P Nurmi says:

I don’t wish to make it sound like somebody else’s problem, but the input methods are not implemented as part of Qt Quick Controls 2, but in the platform plugin of the Qt for Android port so they work for any editors in Qt. However, I fully agree that this is not behaving as it should. Evidently, text editing is one of the hardest things to get right when not using actual native controls. The behavior is also quite different even between different Android versions.

Yann Lanthony says:

Nice job with QQ2.3 ! I’ve been testing it in beta for a few weeks and the Fusion style is really nice for Desktop applications.
I have a question regarding palette customization: how can I override styles for Disabled/Inactive color groups ?
Because it seems that only the default group is available at a Control level.

ApplicationWindow {
palette {
window: “#222”
….
}
}

The only way I’ve found is to do it globally on the C++ (well Python in my case) side.
Thanks !

J-P Nurmi J-P Nurmi says:

Thanks Yann! Even though palettes look like typical grouped properties, they are actually implemented as light-weight value types under the hood. This is great from performance perspective, but it has one unfortunate limitation. Namely, we cannot have nicely grouped sub-properties for the color groups (e.g. “palette.disabled.buttonText”), but we would basically have to add them all as prefixed propertiers (e.g. “palette.disabledButtonText”). While we were on the edge to do that, we decided to hold it back for now since one can use QML bindings instead (eg. “palette.buttonText: enabled ? #333 : #666”).

Yann Lanthony says:

Thanks for you answer and explanations ! Indeed, defining palette properties based on whether the Control is enabled works well to define a “local” style for this Control.
IMHO, also having access to “palette.disabledXXX” would actually be quite useful to define a theme at Application level, where we would not rely on the ‘enabled’ property of a specific Control. This is what I’m doing on Python side, by defining a global QStystemPalette with Disabled and Inactive variations. This way, all my Controls behave the same depending on their state. Does it seem like an interesting use-case to you, being able to do that fully on the QML side ?

J-P Nurmi J-P Nurmi says:

Yes, the use case is well understood. ๐Ÿ™‚ We just didn’t want to rush in a solution that felt suboptimal, because then we would be stuck with that. Let’s see how high demand there is for this, and if there’s anything we can do on the QML engine level to make it possible for us to provide more satisfying API.

By the way, you can also specify a global palette, including the disabled color group, in :/qtquickcontrols2.conf. For example:

[Fusion\Palette]
Text=#333
Disabled\Text=#666

Commenting closed.

Get started today with Qt Download now