[Interest] Guide me through the Qt offerings for GUIs

[Volker Hilsheimer]

> Em 15/04/2021 11:57, Volker Hilsheimer escreveu:
>>> On 15 Apr 2021, at 12:25, Rui Oliveira <ruilvo at hotmail.com> wrote:
>>> 
>>> Hey,
>>> As per the title implies, I would like some comments on the GUI offerings Qt currently has.
>>> 
>>> I'll share my own assessments and needs, and I'd like very much to hear your comments.
>>> 

[…]

>>> In summary, it would seem that my options for the desktop with Qt are two self-competing technologies: one "half-dead", one "3/4-baked"... I'd really love to be wrong.
>> 
>> TL;DR: Qt Widgets will be with us for a long time, and we’ll continue to maintain them and make sure that they continue to work and look great on future versions of the various operating systems as well. There’ll probably always be applications for which the widget concepts are a perfect fit.
>> 
>> For an increasing amount of applications and environments however, Qt Quick provides the better architecture, and we see a growing number of Qt Quick based desktop applications already today, also outside of the KDE environment. But yes, making Qt Quick a first class toolkit for desktop use cases is work in progress and there’s a lot of catching up to do. Native look’n’feel on Windows and macOS was introduced with Qt 6.

> On 15 Apr 2021, at 14:01, Rui Oliveira <ruilvo at hotmail.com> wrote:
> You could have sent me the YT link hahah. I already had a Qt account, so whatever. Interesting discussion.

Oh right, I didn’t check YouTube.

> So what do you identify as the missing features of Qt Quick for desktop and what are Qt's priorities and ETAs?

The functionality gap between the ItemViews in Qt Quick and their QWidget-based counterparts is something we are working on right now, so expect some improvements in Qt 6.2.

A major widget-world feature that is missing in Qt Quick is graphics view. That’s not high on our list of priorities right now though, so no ETA.

On the framework side: the layout engine in Qt Quick needs to work better with resizable windows. Compared to widgets, what’s missing are thing like “minimumSizeHint”, on-demand calculation of sizeHint, height-for-width, size policy. Some of that can be done today using attached properties, but it’s not a great solution. No immediate plans for that yet, either.


Architecturally, one of the desktop concepts that is challenging in Qt Quick are UIs with multiple toplevel windows. This tends to be problematic in a GPU-backed scene graph/render loop architecture. Now, most modern desktop applications (say, Slack, Spotify, or also Microsoft apps such as Teams or the new Outlook) are moving away from “dialogs as toplevel windows”, and even popup menus only live within the scene of the main window. That works already with Qt Quick as well, but some of the “old way” needs to be possible (for instance, app menus on macOS, or system dialogs).

Another challenge is widgets that show content that is significantly larger than the viewport. Large text documents for instance. This needs work, the scene graph needs to be populated as you scroll through the document, without any noticable drop in performance.

We (as The Qt Company at least) plan to spend some time on these architecture items after the 6.2 release.


Volker