[Interest] Guide me through the Qt offerings for GUIs

[Jason H]

> Sent: Thursday, April 22, 2021 at 4:50 AM
> From: "Volker Hilsheimer" <volker.hilsheimer at qt.io>
> To: "Bernhard Lindner" <private at bernhard-lindner.de>
> Cc: "interest at qt-project.org" <interest at qt-project.org>
> Subject: Re: [Interest] Guide me through the Qt offerings for GUIs
>
> > On 21 Apr 2021, at 22:39, Bernhard Lindner <private at bernhard-lindner.de> wrote:
> > 
> > 
> >> Personally, I think the exsting QtQuick element should be scrapped and just focus on QML
> >> versions of the existing Widget functionality. I love the QML syntax, hate that it's not
> >> just a layer on top of widgets.
> > 
> > +100
> > 
> > Why this wasn't done from the start is one of the hardest puzzles! I ask myself this
> > question every time I read the three letters "QML" :-) 
> 
> 
> Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and wondering why there are several UI frameworks.
> 
> But there are several reasons why things are as they are. Some of them:
> 
> * imperative painting
> 
> Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs like to work. Without a persistent scene graph that is uploaded to the GPU, much of the performance you get from a GPU is lost. An animation at 60fps is ideally just a draw call on the GPU with some different transformations, not a completely new upload of a completely reconstructed scene graph for each frame.
> 
> 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.
> 
> 
> * integer coordinates and clipping
> 
> Widgets work with integer coordinates, which starts to be problematic now that we have high-DPI displays. And widgets clip are clipped to their parent geometry, which was the right choice for those UIs, but is very limiting and requires a lot of complex code to solve conceptually simple problems. Hello macOS focus ring.
> Quick items do not clip and are not clipped, which gives a lot more freedom in how shapes are combined and structured.
> 

The painting problem I understand, and as I understand it, the biggest reason for the break?. It's different world. But Integer coordinates don't seem like such a big deal.

> * declarative vs imperative APIs
> 
> Many widget classes don’t have a declarative-friendly API. Plenty of widget properties have side effects on other properties, so the order in which properties are set matters. That doesn’t work well in a declarative world.
> 

I don't buy this. You can do declarative to imperative mapping. Isn't this what the QtQuick compiler does?

> * weight
> 
> Widgets are heavy, often very complex objects. They often come with all bells and whistles. QPushButton always has the data structure to support QPushButton::setMenu, even if probably <1% of buttons out there ever use that feature. That’s ok on desktop machines, it’s not ok on embedded systems.
 

I have a hard time buying this one as well because you've added GL, which requires additional hardware. Sure emulate it in software if you dare, but it's worse than painting.

> * complexity and hard to customize
>   
> Inheritance and reimplementing are nice concepts on paper and works great if you build your own custom widget from a reasonably abstract base class. But if you have ever tried to subclass e.g. QTreeWidget to modify how certain interactions work, then you know how hard it can be to not break the complex states that the default implementations rely on.

The "inheritance" in QML is outstanding. Super simple and effective.
 
> 
> So, making widgets work in a declarative, GPU friendly world where ease of customisation is more important than standard look’n'feel would have required many changes to widgets. Those would have been impossible to make without invalidating or breaking a lot of code out there, and still not given us the UI components we would have needed.
> 
> I’m sure there are opportunities to share more code between widgets and quick world esp on the UI framework classes, and with Qt 6 we have taken some steps into that direction. But whether the benefits outweigh the risks and effort requires a case-by-case evaluation.

I think that's a false choice. 

Anyway, I hate using QML for any kind of text input because it's so crunchy even today. Why do I have to set `selectByMouse: true`? 

I don't understand why the layout system, one of the best, most awesome things about old Qt, what make me fall in love with Qt (aside from the clean API), was abandoned. I don't see why traditional layouts had to be yeeted even if the widgets had to be replaced. The painting issue I get. Sure, thre might be Row and Column replacing VericalBoxLayout, HorizontalBoxLayout, etc. But working with the replacements (Hey, I like shorter names -less typing-) is a crunchy experience. Dealing with childrenRect, implcitWigth/height, etc. New concepts that, in a transitional time made the transition harder. QML has not been the ideal, it's 12 years old, people are still debating if it should be used. I think harmonizing the two, and providing classic APIs will reduce the need to make that choice, which in the end, is just choice between painter or GL operations.

Also, I am using mingw on Windows with QML for the first time in years, and that experience is crunchy. Fonts look terrible and there's glitching in the app, that looks like a GL issue.