Digia To Spin Off Qt Business Into Its Own Company

[anda_skoa]

I think the difference between you and me is that we see differently on our C++ layers
In my projects I always have many layers, not only core and data layers with business logic, but more UI centric layers of code like QML components implemented in C++ and view models.

Sure, I do that as well, e.g. have application specific QML instantiatable types.
Maybe core was a bad naming on my part. What I meant is that part of the application that is always there versus the bits that are instantiated through QML.

This first, fixed, part is what I referred to as the core. This part should not need to know about anything that the QML engine could potentially have instantiated, especially not any UI types.

Otherwise I need different code paths in there, potentially using #ifdefs, etc.

Of course that will not always be possible, but it is a goal which needs very good reasons to abandon.

Behaviors are nice, I use them a lot (mainly to get around named limitations in QtQuick) but I still don't feel that it's declarative enough.
Having to assign an id to my UI components in the QML files and invoking methods on them there is not what I would consider "pure".

But isn't direct access to a pointer to a specific type and invoking methods on them even worse?

As a third alternative for the animation example, what about binding to the animation's "running" property?

Therefore, my wish is for all official QtQuick components to be created in C++ (ApplicationWindow.qml, I am looking at you) and with a public API

Sure, would be nice for corner cases.
But my experience with two frameworks that do both C++ and QML instantiation (Cascades and QtWidgets) is that I tend to fall back to C++ out of laziness, because doing it properly would have required a cleaner separation and slightly more upfront work but of course advantageous in the long run.

Cheers,
_

[Znurre]

But isn't direct access to a pointer to a specific type and invoking methods on them even worse?

Haha, I don't know. It's C++, I don't mind writing imperative code there, as long as it's all typed

As a third alternative for the animation example, what about binding to the animation's "running" property?

This is a very fair point.

But my experience with two frameworks that do both C++ and QML instantiation (Cascades and QtWidgets) is that I tend to fall back to C++ out of laziness, because doing it properly would have required a cleaner separation and slightly more upfront work but of course advantageous in the long run.

Cheers,
_

Just out of interest, how did you work with QtWidgets through QML?
Through the Declarative Widgets project from KDAB? Or did you put together something by yourself?

[anda_skoa]

Haha, I don't know. It's C++, I don't mind writing imperative code there, as long as it's all typed

My main concern in this case is that there is a raw pointer being passed through the separation layer and, from my point of view, in the wrong direction.

Just out of interest, how did you work with QtWidgets through QML?
Through the Declarative Widgets project from KDAB? Or did you put together something by yourself?

Yes, using DeclarativeWidgets.

It is another one of those eye openers for me.
Theoretically it or a similar module would allow me to write a mobile app with, e.g. native BB10 Cascades, UI and detect attaching of an external screen and keyboard/mouse and load a full features desktop-style widget based UI.
Or for convertiables, assuming one can detect the switch.

Or for having a desktop application with highly configurable UI.

Cheers,
_

[weleini]

This action will help the spin-off do better on its own without the distractions of the core company; and will help the core company focus more intently on the products and services that fit together in its core vision/mission.