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
<kshegu...@gmail.com> escreveu:
On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest
<interest@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@qt-project.org
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
