<div dir="ltr"><div dir="ltr">On Thu, Apr 22, 2021 at 11:56 AM Volker Hilsheimer <<a href="mailto:volker.hilsheimer@qt.io">volker.hilsheimer@qt.io</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* declarative vs imperative APIs<br>
<br>
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.<br></blockquote><div><br>This is hard to agree to. The widget designer outputs XML, which is as declarative as you can get. While QML's syntax is nicer you have the same argument going for it (e.g. the dreaded circular bindings).<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* weight<br>
<br>
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.<br></blockquote><div><br>Eh! I agree for the imperative painting and not being able to batch and render efficiently, but you really think that a QWidget window has more objects than a QtQuick scene? I will be hard pressed to believe that. Moreover with the widgets you don't need everything to be QObject (or in some cases Q_GADGET), or wrap everything in QVariant, or introduce global factories like `Qt.vector3d` just due to the fact that you're working on a lower level and you don't have to battle with the JS engine. I will concede that the widgets were conceived in another age so they have a lot of shortcomings, but 'heavy, often very complex objects' doesn't seem to be it, especially if you're drawing a parallel to QtQuick. Anyone can go and see the internal implementations of the QtQuick items if he/she doesn't believe this.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* complexity and hard to customize<br>
<br>
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.<br></blockquote><div><br>Yes, somewhat true. But this does go to the time the widgets API was designed. It could as well have been using more aggregation and more flexibility then (not placing blame). For example it could've been possible to designed the tree widget to accept delegates that are not directly painting, but rather are issuing jobs for the (hypothetical) painting engine. And there could've been an effort to aggregate complex controls instead of deriving (QComboBox comes to mind) where customizing elements could've been done through delegates, but it is what it is. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br>You should mentioned that by 'declarative' you mean the way you want to render in batches/jobs (nothing wrong with this, btw.). The widgets (the forms specifically) are declarative enough, the problem is that when you start painting them you end up constantly setting and resetting the painting state.</div></div></div>