[Interest] Guide me through the Qt offerings for GUIs

[eric.fedosejevs at gmail.com]

> From: Interest <interest-bounces at qt-project.org> On Behalf Of Vlad Stelmahovsky
> this Slack client clone created using C++/QML (Desktop app, built for Linux/Windows/macOs)
> https://user-images.githubusercontent.com/11473810/55072233-d58ce380-508a-11e9-9e6a-b6b80fc83dd6.png?raw=true

Thank you for an actual example of a desktop application using QML! Though it does look like a bit of a mess and not at all like a useful mouse-oriented desktop productivity application.

> From: Interest <interest-bounces at qt-project.org> On Behalf Of Volker Hilsheimer
> Sent: Thursday, April 22, 2021 4:51 AM
> Widgets can draw into a framebuffer texture that can be used, and that allows for some integration, but that doesn’t give you great performance.

Computers have been blitting onto screens at high refresh rates since Pong. On what target device is blitting performance a limitation? If there are target devices so low powered that they struggle to blit, how is the situation improved by adding an entire Javascript runtime backend? And can you not almost entirely solve this problem by rendering widgets directly from textures?

> From: Interest <interest-bounces at qt-project.org> On Behalf Of Volker Hilsheimer
> Sent: Thursday, April 22, 2021 8:24 AM
> We currently have no specific plans to make QWidget render through RHI, and neither the video nor my earlier emails suggest that this is on the roadmap. It generally makes very little sense to draw with a pen into a freshly wiped out Vulkan surface > 60 times per second.

Why are QWidgets not rendering almost everything directly from texture? Except when styles are changed, there should almost never be a need to blit a widget. There is nothing intrinsic about widgets (vs. quick controls) that requires them to be blitted onto a freshly wiped surface 60 times per second, only inertia and a lack of desire to make any improvements to the widget backend in over a decade.