> Sent: Thursday, April 22, 2021 at 4:50 AM > From: "Volker Hilsheimer" <volker.hilshei...@qt.io> > To: "Bernhard Lindner" <priv...@bernhard-lindner.de> > Cc: "interest@qt-project.org" <interest@qt-project.org> > Subject: Re: [Interest] Guide me through the Qt offerings for GUIs > > > On 21 Apr 2021, at 22:39, Bernhard Lindner <priv...@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. _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
