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