[Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo]

22/04/21 20:38, Konstantin Shegunov:
> On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest 
> <interest at qt-project.org <mailto: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.

I think I'm missing some context: when you say "isn't that" or "isn't 
it", what "that"/"it" are you referring to?


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

"Controller" is an extremely overloaded word. Could you please clarify 
what design are you referring to?

I don't understand some of your points, like "UI that's completely 
decoupled from the business logic". What does this mean -- shouldn't the 
business logic be the one decoupled from the UI? Are you talking about 
UI testing (via a mock business implementation)?


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

Sure it is! I said it myself, it's typically not just one magic 
do-it-all layer, but multiple layers. In those layers you

* adapt business logic datatypes into Qt datatypes;
* write Qt models wrapping business logic datasets;
* expose the relevant business logic in QObjects;
* create custom UI components;
* write state machines and what else is necessary to drive the UI based 
on the business logic state;

and so on. All/most of this gets done in C++. Some other bits may be 
done in QML, if it makes sense. The important message here is that such 
adaptation / UI logic layers do exist in any non trivial application, 
and the fact that from QML you just can't "just" reach into business 
logic, you need to jump through the language border, giving you a 
significant chance of making the integration more "clean".



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

... I don't see how using JS magically allows you to call functions into 
your C++ business logic?


> 
>     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 write FORTRAN in any language".

The point I was trying to make is this: you need to write some degree of 
QML/C++ integration code to make the two worlds communicate. This, at 
least, gives you an excellent chance of clearly separating UI from 
business logic. That chance doesn't guarantee not doing a complete mess, 
but at least it's there.

(Then, as I said, you should also write most of your _UI logic_ itself 
in C++ as well. And now we have at least two layers. And so on an so forth.)

Now, am I saying that the C++/QML integration is absolutely perfect and 
you'll never write cleaner UI code? Of course not, there's still tons of 
shortcomings and annoyances that will make you say "sigh" and take 
shortcuts here and there.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210425/35660682/attachment.bin>