Digia To Spin Off Qt Business Into Its Own Company

[anda_skoa]

Qt5 has only raster backend (graphics system) for Widgets which means no HW acceleration.

If a platform has a GPU accelerated 2D drawing API, the platform plugin for that system can provide a backend based on that API.

Currently that is not the case because the raster backend is quite sophisticated, using CPU hardware acceleration features (e.g. SSE3) where possible:

Cheers,
_

[carewolf]

Yeap. Quite frankly the way Widgets paint themselves will not benefit greatly from OpenGL acceleration anyway. QWidgets paint by drawing a line here, changing the color and then drawing a couple of pixels there and switching the color back and then drawing some more pixels elsewhere. That is fundamentally incompatible with how OpenGL works: Changing drawing state is rather expensive, so you should try to chunk similar operations together instead of switching between states all the time. So there is little point in even trying for OpenGL-accelerated rendering of QWidgets.

There actually were HW-accelereated renderers for QWidgets using other technologies though. But experience showed that the unaccelerated raster engine outperforms those on modern hardware! The raster engine also tends to cause viewer drawing glitches, so that is what QWidgets uses nowadays (except for some very special cases for really low power devices IIRC). That leaves you with no HW acceleration for your QWidgets -- and still better performance than before;-).

You can still render QWidgets hardware accelerated if you want. It is just not the default on any platform, and it is usually not that good an idea. But a QOpenGLPaintDevice can be created (using either an OpenGL window or framebuffer) a QPainter opened on the paint device, and QWidgets painted onto the qpainter using QWidget::render.

Basically most things in QtGui renders using QPainter, and QPainter still has an OpenGL backend, and one that continues to be improved. But it mostly makes sense if you need 3D transforms or blend of large images on embedded devices with decent GPU and weak CPU.

[Znurre]

A lot of uninformed talk in this forum, let me try to cover most of the misunderstanding of the technology and some questions...

Just had to give my opinions on a few of your points here, as I don't agree with them.
First of all, I really like QML - I think it's a great idea in general, but I don't like QtQuick much.

"It bothers me that the head of Qt engineering said in his keynote address at the Qt Developers Conferense that Qt Widgets are done." - It means it is stable and there are no more features to be added because it would go out of the scope of the module. That's like you making a car and finishing the car but it's not done because you want a football field in it to be integrated... It's out of the scope of the car, there is a better place for a football field...(Might not be the best example, but I hope you get the point).
They still develop and maintain the C++ libraries, no one develops in JavaScript... JavaScript in QML is just a convenience - you write the logic in C++ and leave the UI to QML which is way better suited for it, the 2 communicate one with another very nicely...

There are still a lot of things to add to QtWidgets that are in the scope of the module.
Data bindings for example, and there are times where I've found myself thinking "why isn't this simple feature available?" though I can't recall any right now.

"For starters it looks bad - at least the Quick controls. They give your app a Java Swing look. There are no themes for QML, every QML piece lays itself out chosing its fonts, colors, margins, sizes - its like trying to take a video like "Girls Gone Wild" and make an epic movie out of it. I wont even talk about the overhead and complexity of passing C++ to/from QML." - I have the impression you talk about QML 1, not QML 2... QtQuick Controls look as native as QWidget looks in a desktop environment(on mobile QtQuick Controls look better). You can easily make your applications themable with QML, bindings make this kind of stuff Very-Very easy to do... "margins, sizes..." - I'll say just: Qt Quick Layouts. And there is not much overhead because you are not passing data around to be processed. In applications where you combine QML and C++, QML just tells C++ what to do with the data, it doesn't get the data and passes it to C++, you are confusing how these things work... Can't really explain it well in a forum...

As of Qt 5.3 applications written using QtQuick Controls still don't look native.
With the Oxygen style for example you have no radial gradient, you don't have proper backgrounds for some elements, etc.
On Windows the controls don't look anything like the native controls, though they do look better I have to admit :P

- JavaScript in QML is optional, it's a convenience. It's a solution to the design flaws that WPF and FXML have... You don't have to jump into C++ for some simple stuff like in the case of those 2 older technologies...
- For complex applications it's intended to use C++ for the logic and QML for the user interface. No one uses JavaScript for heavy stuff, just drop this stupid talk. And the connection is made very nicely...

The problem is in the implementation of QtQuick.
It basically forces you to use JavaScript for implementing logic because a lot of classes are private and only exposed through QML.
For example, the Animation class, the ApplicationWindow class in QtQuick Controls (this one is even implemented only in QML...), the drag and drop classes, etc.

The only option is to:

• Handle and access them through JavaScript logic.
• Use "reflection" from C++ using QMetaObject/QMetaProperty/QMetaMethod to interact with them in an untyped way.
• Copy the private header files from Qt, cast to those types and pray that they don't change.

In my opinion no logic should be written in JavaScript.
I want to use QML only to build an UI structure and bind it to my C++ view models, and to ALL logic in C++.
This is not possible with QtQuick in its current state, sadly, and I think this is the reason why many people have a bad impression of QML in general, while the fault really lies in QtQuick.

[anda_skoa]

First of all, I really like QML - I think it's a great idea in general, but I don't like QtQuick much.

I can fully relate to that.

My initial reaction to "QML" was also dislike, because I hadn't understood the distinction between QML and QtQuick yet due to so many people using it interchangably.
And QtQuick was in my opinion more a toy technology, unfit for anything a spohisticated application would need.

My personal eye opener was the BlackBerry10 Cascades framework, which also utilizes QML, also utilizes a scene graph but, similar to QtWidgets, has a full features set of standard controls.
Incidentally its controls can also be used from C++, so it is always a matter of the current use case (in most cases QML will have the advantage though).

The same thing can be done with QtWidgets as well, i.e. using QML as way to create QtWidget based UIs and also having the choice to fall back to C++ if the use case requires that.

In my opinion no logic should be written in JavaScript.
I want to use QML only to build an UI structure and bind it to my C++ view models, and to ALL logic in C++.

I think that is mostly what everyone working on large enough projects agrees on.

This is not possible with QtQuick in its current state, sadly, and I think this is the reason why many people have a bad impression of QML in general, while the fault really lies in QtQuick.

Well, in my experience it is not that bad. Can you give an example of logic that has to be implemented in JavaScript?

Cheers,
_

[Znurre]

Well, in my experience it is not that bad. Can you give an example of logic that has to be implemented in JavaScript?

Sure

Take this for example:

	
DropArea
{
	anchors.fill: parent
	onDropped: // <- problem
}

The signal dropped of DropArea has a parameter of type DragEvent (QML).
The underlying C++ class, QQuickDropEvent, Is declared in qquickdroparea_p.h, so definitely not public API.
Therefore, you simply cannot pass this parameter with type safety to an underlying C++ model.

The same goes for QML types like Animation.
If you want to do your own state machine class for example for handling transition between screens you might want to do something like this:

StateManager
{
	...
	availableStates: model.availableStates
	currentState: model.currentState
	animation: NumberAnimation
	{
		...
	}
	...
}

And then execute this animation from C++ when you change the state.
Well, too bad, the Animation C++ type (QQuickAbstractAnimation) is declared in qquickanimation_p.h, also not public API.

Hence, you need to expose it as a QObject* property and use QMetaObject and QMetaMethod to invoke start() on state changes.

These are just a few examples.
The whole QtQuick API has these kind of types only exposed to QML

[anda_skoa]

The signal dropped of DropArea has a parameter of type DragEvent (QML).
The underlying C++ class, QQuickDropEvent, Is declared in qquickdroparea_p.h, so definitely not public API.
Therefore, you simply cannot pass this parameter with type safety to an underlying C++ model.

Hmm. I guess this is a border line case, i.e. whether one considers the event to be a user interface type or data.
You seem to think of it as data which you want to pass to C++, I would consider it a user interface type, something I don't want my C++ code to deal with.

The same goes for QML types like Animation.

In this case I am surprised that you don't consider that an UI element.
I would ideally never want my application core to depend on the UI, something that QML in general (independent of UI component set being used) make easy to spot and to avoid.

Hence, you need to expose it as a QObject* property and use QMetaObject and QMetaMethod to invoke start() on state changes.

Right, but why would the C++ part of the code need that?

From my point of view an animation is something that the UI parts of the application decides to use, which it can start or stop whenever it wants to.
My C++ state machine would not care a bit about that.

In such cases I find the privateness of types really helpful to detect when one would have accidentally created a core -> UI dependency instead of havng a UI -> core dependency.

Cheers,
_

[pingufunkybeat]

The article says the new company will be wholy owned by Digia.

They should call the new company "Trolltech".

[Znurre]

Hmm. I guess this is a border line case, i.e. whether one considers the event to be a user interface type or data.
You seem to think of it as data which you want to pass to C++, I would consider it a user interface type, something I don't want my C++ code to deal with.


In this case I am surprised that you don't consider that an UI element.
I would ideally never want my application core to depend on the UI, something that QML in general (independent of UI component set being used) make easy to spot and to avoid.


Right, but why would the C++ part of the code need that?

From my point of view an animation is something that the UI parts of the application decides to use, which it can start or stop whenever it wants to.
My C++ state machine would not care a bit about that.

In such cases I find the privateness of types really helpful to detect when one would have accidentally created a core -> UI dependency instead of havng a UI -> core dependency.

Cheers,
_

I think we have to agree with disagreeing then
I want my QML definitions to be 100% declarative.
Only property bindings, and in case of signals, one direct method call forwarding it to the model.
No logic in the QML files at all, not even UI logic, hence my emphasis on implemting ALL logic in C++ in my first post

I don't think it's wrong to put UI logic in the controls (the StateManager example, it might not have been very obvious but to me it's not much more than a glorified Loader component) or in the view models (that's why you have view models afterall ).
Even though I don't like C# and .NET, I have to admit that Microsoft got it right with WPF.
The UI being 100% declarative and all logic being implemented in code behind.

With QtQuick this becomes very hard.

[anda_skoa]

I think we have to agree with disagreeing then
I want my QML definitions to be 100% declarative.
Only property bindings, and in case of signals, one direct method call forwarding it to the model.

I think we actually agree on this.

I just additionally don't want my core to depend on the UI at all, I want to be able to do let the QML engine instantiate QtWidgets or BB10 Cascades, etc.
Passing handles of UI objects into the core defies that goal, these are very likely specific to the component set being used.

In the case of the drop I would pass the drop data items that I need in the core.
In the case of the animation I would either trigger the animation on property change (property change handler or Behavior in QtQuick) or let the state manager emit a signal and connect to that.

Cheers,
_

[Znurre]

I think we actually agree on this.

I just additionally don't want my core to depend on the UI at all, I want to be able to do let the QML engine instantiate QtWidgets or BB10 Cascades, etc.
Passing handles of UI objects into the core defies that goal, these are very likely specific to the component set being used.

In the case of the drop I would pass the drop data items that I need in the core.
In the case of the animation I would either trigger the animation on property change (property change handler or Behavior in QtQuick) or let the state manager emit a signal and connect to that.

Cheers,
_

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.
This code is very tied to the UI and abstracts away the business logic, and this is where I want my behavior and UI logic.
Making data layer and business logic dependent on UI classes is, as you said, definitely not good.

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".

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