[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

I agree absolutely with these observations, in principle.

But this seems to be "easy" when we're talking about an application 
displaying data, with a fixed set of controls. Flashback to all the QML 
tutorials using model/view + delegates.

In my particular case (and it's not unique to me at all), I have a 
series of devices that I'd like to support, which have completely 
different and unrelated controls. This might be my "stuck mindset" 
talking, but I've seen this problem solved as I explained: "bring your 
own controller", and yes, a widgets object and a "logic" object with 
pointers to each other. I've "stolen" this idea from projects I've 
seen.  Add wish to have a plugin system, forcing an even more dynamic 
system, and I don't know how to solve the problem without this 
architecture.

And this is the only way I can think of doing it. I would really like to 
know other way, so if anybody has pointers, I'd be glad to hear them.

And if I need to chain parameters on my hardware, how do I do it without 
calling a method on the hardware object from a signal connected to a 
slider? Again, keeping it isolated from the rest of the system, because 
I don't know, not even at compile time, the controls needed. It's not 
like I can just do it with a "Flux" architecture.

Maybe I'm absolutely terrible at software design. I'm not a software 
engineer.

Rui

Em 22/04/2021 17:17, Giuseppe D'Angelo via Interest escreveu:
> On 22/04/2021 17:06, Rui Oliveira wrote:
>> Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would 
>> otherwise be just business logic because you need to access something.
>>
>> I've linked this before: 
>> https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
>>
>> Which again, is absolutely trivial do to with C++ and polymorphism. 
>> And a pointer/reference instead of adding macros in 20 places  and 
>> the Q_PROPERTY lines...
>>
>> Basically we're coupling the whole backend to the GUI framework.
>>
>
> Wait, this sounds precisely what you shouldn't do.
>
> 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.
>
> (Possibly even more layers. Like an cake. Or an ogre)
>
> This way
>
> * the business logic is agnostic of the UI framework used above (could 
> be Widgets, could be Qt Quick, could be HTML)
>
> * you can do UI testing by swapping out the business logic with a 
> testing one
>
> * you can test the business logic without the UI
>
> and so on.
>
>
> 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.
>
>
> 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!).
>
> And/or thought "ok, I should add a controller for the UI layer that 
> talks to these other 5 objects, and does this and that, and gets 
> triggered by the button... or I could just #include 
> "Component_Deep_Into_Business_Logic.h" and just call a method on it.". 
> You know, "a little goto never hurt anyone". (Velociraptor ensues)
>
>
> In other words, being "entirely" in C++ has also its downsides.
>
> HTH,
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210422/02890ce6/attachment-0001.html>