[Interest] Guide me through the Qt offerings for GUIs

[Henry Skoglund]

On 2021-04-25 13:56, André Pönitz wrote:
> ...
> 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'

Hi, re. backend/frontend glue i QWidget flavored apps:
you could also say that some "glue" will appear when you choose a 
QTableView instead of a QTableWidget in your Qt app.
IOW, most of the time (at least in my apps) working directly with a 
QTableWidget gets the job done easier/faster. Of course the QTableView 
model stuff is useful in some cases but I think the default design 
choice should be the plain widget.

Rgrds Henry
P.S. Reminds me of another, slightly similar discussion: which design is 
best, a monolithic kernel like Linux or a microkernel like Fuchsia :-)