[Interest] Guide me through the Qt offerings for GUIs

[joao morgado]

 Olá Rui
Just to share my experience with Qt widgets and QML. I had a simple desktop calculator app with Widgets and OpenGL graphics. I had a c++ mindset and was ok doing that. When QML come around it was a bit strange and I had to leave my confort zone. Eventually QML syntax become so pleasent to me and I found myself really enjoyng developing with qml / javascript. I ported my app to QML based on the OpenGL under QMLexample. I started porting in the QML early days so I had to do a lot of "widgets" in qml from scratch wich was a bit of work. My app looks a lot better in QML and works for android and iOS with consistent look  and feel in all plataforms.Also I find the qml development much faster than c++.
I also developed a game in qml. It has almost no relevant UI, but I had a very pleasent experience using javascript and qml features for the game logic (hello qml bindins, hello qml timer sintax). I never had performance problems, as some people say that javascript is slower than c++, but at the end of the day I think it also has a lot to do with your code algorithm and the type of app your developing. Btw I never had developed with javascript before, but if you are a c++ developer you will have no problems at all. 
If I had to start a new app today for desktop I would go for QML. Your app is for desktop today, but you never know when your users will start asking for a mobile or tablet version. 
CheersJoão

    Em quinta-feira, 22 de abril de 2021 19:41:06 GMT+1, Konstantin Shegunov <kshegunov at gmail.com> escreveu:  
 
 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._______________________________________________
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/90ab8773/attachment.html>