[Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest <
interest at qt-project.org> wrote:

> You should create a C++ layer (call it a "presentation" layer) that sits
> between your (possibly non-Qt) business logic and the UI. That layer
> contains stuff like item models, QObjects that expose the relevant
> business logic APIs, type wrappers, and so on.
>

Registering a struct/data class with the meta type system and/or marshaling
it over QVariant, just so it can be visible in QML isn't that. Or things as
natural (with C++) as having the UI raise some encapsulated piece of data
in a signal (say some struct, say QColor or QVector3D) which the backend
responds to isn't it either. As a matter of fact, how do you tie your
existing backend to QML? Say we have this nice encapsulated UI that's
completely decoupled from the business logic, how do I tie a specific
object from the Quick scene and connect the notifications back to C++? I
can't do it from the business logic (i.e. controller side), I have to
expose the backend to the QML engine and do it from there, am I wrong?
Basically you say it's fine that the UI drives the controller (incl. object
creation)?

We can agree on the principles, gladly, but this is really a gross
oversimplification of the problem.

While building this layering may be super tedious (YMMV), in the long
> run, it makes your application more robust, not less. The fact that QML
> _forces_ you to have this stuff becomes somehow a good thing.
>

Forces you? Do you mean, perhaps, that JS is somehow not supported, or
maybe that Component.createObject is somehow hidden and/or inaccessible?

On widgets, well, raise your hand if you didn't at least once connect a
> QPushButton to a slot declared in the widget that contains the button,
> and perform some business logic from there (yay business logic in the UI!).
>

Yes, it is done, and not without an honorable mention of the documentation,
where the view-controller idiom is used extensively.  But then, raise your
hand if you at least once didn't use an `if` (or some other JS piece of
code) in a QML file. I can pull out for you numerous cases of it being
done, probably too numerous to count even in the examples. Shooting
yourself in the foot is not restricted to one language or another, nor to
the technological solution in use is my point. You can make a holy mess of
any piece of code on any language you choose, and QML certainly doesn't
force you to do anything you don't *really want to*.

In other words, being "entirely" in C++ has also its downsides.
>

Most certainly. One of the major downsides is it being much more complex
and unforgiving, which doesn't necessarily mean it's better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210422/ccad6c6b/attachment.html>