[Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 11:56 AM Volker Hilsheimer <volker.hilsheimer at qt.io>
wrote:

> * 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.
>

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).


> * 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.
>

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.

* 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.
>

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.

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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210422/3134b8a5/attachment.html>