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-72b67caf5...@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' _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest