[Interest] Guide me through the Qt offerings for GUIs

[André Pönitz]

On Wed, Apr 21, 2021 at 05:31:33PM +0100, Nuno Santos wrote:
>    For me, the major benefit of Qml is speed. Before using Qml I’ve done a
>    couple of years doing Qt Widgets. The glue code to make things work is a
>    big pain.

Hi Nuno.

This is an interesting statement.

My personal experience is exactly the opposite: By using Qt Quick one is
forced to use non-trivial amounts of glue code that is conceptually
unnecessary in the QWidget case.

As a concrete example: A while ago I converted Qt Creator's Welcome screen
(on the UI side essentially the thing that you see whe selecting the Welcome
mode plus a bit of helper code) from Qt Quick to QWidgets. The driving force
behind that change were re-occurring issues in setups with limited or
"broken" OpenGL support and the overall application startup time previously
dominated by this rather small plugin. Having to tell people to run with
"-noload Welcome" to mitigate these created a rather unwelcoming user
experience.

Besides solving the actually triggering problems this had the (not
completely, but surely at this level unexpected) side effect of reducing the
overall code side considerably: The original setup consisted some C++
"backend", the QML "frontend" and the "glue" to expose the backend to the
frontend (i.e. what Peppe calls "presentation" layer in Message-ID:
<421f4e26-dc6f-c06f-782f-72b67caf536f at kdab.com>). I do, btw, agree this is
indeed "best practice" for a Qt Quick application, so the original
implementation was ok, given the limits of the chosen technology.

For the replacement I had to do add some custom finger-painting code with
e.g. absolute pixel counts to mimic the original appearance closely (which
is, btw, quite unusual for a normal QWidget based setup), but even with that
the total LOC of backend + the complete frontend was less than previous LOC
of backend + glue. I.e. already the absolute number of LOC of the C++ bits
(with shifted functionality) overall decreased, and the QML bits were
completely gone. 

One thing I noticed contributing to this effect is that it is apparently
difficult to pass objects of "medium" complexity through the glue layer.
Simple stuff like integers and strings are fine (enums already get
interesting...), really complex stuff like QAbstractItemModels can be fine,
but for "two strings, an enum and an optional QDir" you already have to make
up your mind whether this is more like "three strings and an int" or more
like "something that needs moc". This contributes to an effect that I
consider self-censorship when it comes to selecting appropriate data
structures for the backend: If I know I can only expose certain types to the
frontend, I am tempted to used these types in the backend, not necessarily
the ones best suited one for the task. If the only tool is a hammer, ...


Anticipating some potential responses here: Of course, using QWidgets you
have at some point a _conceptually_ similar problem of having to associate
your QDir "data" with e.g. a QLineEdit, and your enum value with a QComboBox
or some QRadioButtons in a QButtonGroup. The concept of a "glue" layer
doesn't magicaly go away. However, in this case you have the choice to put
this glue code at a place were they make most sense (and also shift stance
easily once requirement changes), by e.g. putting the "necessary"
"three-line-lambda" in a place where your "logical" backend/frontend divide
actually is. With Qt Quick there is already some divide between .qml and
.cpp after you have prototype, and even when this turns out to be not the
the best place for the cut in the end, or when the requirements change
(a.k.a. "always"...) there is a high inertia to keep the divide as-is, even
if it doesn't fit the problem well anymore - simply because converting even
only a handfuls lines of code between C++ and QML is significantly more
effort then shifting these lines between different parts of a uniform C++
code base.

Please note that I am really not saying that there is no backend/frontend
glue in any QWidget based application. I surely have seen enough code piling
glue layer on glue layer for no traceable reason also for QWidget
applications so I know this generalization is not true. The point is really
that for a _reasonably_ developed QWidget application the amount of
_necessary_ glue is significantly(!) less than the _necessary_ glue of an
equally _reasonably_ developed Qt Quick application.  On top of that go
benefits like being the ability to use the same kind of tooling (debugger,
profiler, static analyzer, ...) for both parts in one go.

As you seem to have made different experiences I'd like to ask whether there
are concrete examples I may look at?

Andre'