[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

Olá João!

Doing logic with QML? hehe I can hear the voice of Jesper Pedersen from 
KDAB saying "your business logic stays in C++" 
(https://www.youtube.com/watch?v=JxyTkXLbcV4 pretty good series, actually).

I'm just kidding, Qt itself has examples in Qt Creator making a game 
without any C++ logic 
(https://doc.qt.io/qt-5.12/qtquick-tutorials-samegame-samegame1-example.html 
and parts 2 and 3).

Thanks for your insights! I see that those who use QML love it, it seems 
to be a consistent feeling.

I'll keep that in mind. Now I guess I need to learn software 
architecture that covers both what I want to do and good practices with 
GUI work.

Thanks,
Rui

Em 22/04/2021 20:33, joao morgado via Interest escreveu:
> 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.
>
> Cheers
> Joã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 <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. 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 <mailto:Interest at qt-project.org>
> https://lists.qt-project.org/listinfo/interest 
> <https://lists.qt-project.org/listinfo/interest>
>
> _______________________________________________
> 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/8680916e/attachment.html>