Digia To Spin Off Qt Business Into Its Own Company

[JS987]

You heard a few words and you think you know everything already... Heard: QML and HW and done, it's only possible with QML...
Go search what QGraphicsScene is, it was available since Qt 4.2! And QPainter which was available since the Qt 3 days...

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

[JS987]

"XML isn't bad if you use modern software with code completion." - everybody step to the sides, the pro is talking...

Luke_Wolf said XML is bad thing which is true if stupid software without code completion is used.

[Alliancemd]

Re

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

- DarkCloud:

"One of the biggest problems Qt suffers from is that it is to much technology driven with software guys calling the shots as to where it goes. Being able to put QT /QML on every smart phone and mobile device gets away from Qt's core strength as a cross platform desktop framework. The desktop market may not be as sexy as the mobile market but thats where the money is." - You could of said that in the Nokia days, it doesn't hold right now. Digia still has a strong focus on desktop because most of its enterprise customers are using it for the desktop. And they don't call any shots, they do contribute most of the code though... There are a good amount of outside contributors(KDE for example). If you yourself for example prove to be a good maintainer of a piece of code that you want to be integrated with Qt, you could do that... Qt Project has an open infrastructure, Digia doesn't have full control of it, it's just so happens that their employees contribute most of the code and because of that, they are the maintainers of the most modules...

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


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

Btw, if you have a QWidget application, you can easily integrate QML into a QWidget interface(QQuickWidget) or a QWidget interface into QML...

- JS987:

For a person that has no idea about programming, you are very opinionated...
- 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...
- "QtQuick idea isn't bad, but using Javascript is. Javascript is used because every web developer is forced to learn it." - makes no sense... Just shows that you have absolutely no idea about the field... Who forces those web developers, btw? Is there some kind of military power, or what?
- "XML isn't bad if you use modern software with code completion." - again, makes absolutely no sense... Go read what XML is, what does it have to do with modern software or code completion absolutely doesn't make any sense...
It's like you are saying: Really couldn't think of a real world example, it doesn't make any sense... I could give an example of a format standard and connect it with "IDEs and code completion" but I am not sure you would know what I am talking about...

- "Qt5 has only raster backend (graphics system) for Widgets which means no HW acceleration. " - again, go read what QGraphicsScene and QPainter are... These are not QWidget! QWidget was intended to be used for simple components and to be minimal, simple and light. For something fancy you would use QPainter in the Qt 3 days. QGraphicsScene is still used by a lot of people even today. And both "use the GPU"(Hardware Accelerated how some would say).

[Alliancemd]

Re

Luke_Wolf said XML is bad thing which is true if stupid software without code completion is used.

How to explain it to you so you understand that XML has nothing to do with code completion...

XML is not a programming language, it's a textual data format.
It's like you are saying: "TXT is bad which is true if stupid software without code completion is used" - I just swapped XML with another textual data format... I really hope this time it gets to you why what you are saying doesn't make any sense...
I might use XML to define a shopping list...
In TXT you would write: "Milk, Batteries, Hat, Cheese"... It doesn't have a standardized way of arranging data like XML.
In XML I could write for example:

<shopping-list>
	<diary>
		<item>Milk</item>
		<item>Cheese</item>
	</diary>
	<electronics>
		<item>Batteries</item>
	</electronics>
	<cloths>
		<item>Hat</item>
	</cloths>
</shopping-list>

A primitive example... Code completion has to do something with these? No!
Does code completion make a format better? Doesn't make sense! It's just a textual format. In this case, a textual format with a defined way of representing the data but it's doesn't tell you how to place those tags, because of that you can't really define what "code completion" would have to do for you in this case.
I could write the same list in another way:

<shopping-list>
	<item>Milk</item>
	<item>Cheese</item>
	<item>Batteries</item>
	<item>Hat</item>
</shopping-list>

Or

<IWriteHereWhateverIDamnWant>Milk, Cheese, Batteries, Hat</IWriteHereWhateverIDamnWant>

What does code completion have to do with the data I defined in this standardized textual format? Nothing! It's just a textual format.


Now to the part why XML is considered "bad": It is an old format, when compared to newer formats, like JSON, it gets outperformed.
In case of JSON, XML has over 20 times slower read times - it takes over 20 times longer to read XML data than it does for JSON.
And there are formats like BSON which are even faster but in this particular case, it's not readable by humans because it's a binary format.

[Alliancemd]

To add

To add: Those tags are there only to make it easier for "machines" to understand it too...

[wardhan]

excuse for being sarcastic

in a year or two, digia has a strong presence in enterprise market.
the fun starts when we have a clogging code. it slows down the qt say for 10%.
and the off-roll contributors [ i mean non-did\gia contributors ] send a patch to remove that particular portion of code & at the same time offer a solution [ i mean a work around ].
the patch triggers might introduce small to medium discussion.
and the top enterprise customers are not happy. they do not want to rewrite their code b'coz it costs them money.
the top enterpise cusomers also call & email digia about their disagreement about removing the portion of the code.
now digia will deliberately let the patch to rot [ i mean never apply ]. why ?
because more than 80% code contributors & resources are owned by digia.

disclaimer: i am just a spectator of open source. i run my laptop with open source os. and i have no experience in coding.

[quikee]

excuse for being sarcastic

in a year or two, digia has a strong presence in enterprise market.
the fun starts when we have a clogging code. it slows down the qt say for 10%.
and the off-roll contributors [ i mean non-did\gia contributors ] send a patch to remove that particular portion of code & at the same time offer a solution [ i mean a work around ].
the patch triggers might introduce small to medium discussion.
and the top enterprise customers are not happy. they do not want to rewrite their code b'coz it costs them money.
the top enterpise cusomers also call & email digia about their disagreement about removing the portion of the code.
now digia will deliberately let the patch to rot [ i mean never apply ]. why ?
because more than 80% code contributors & resources are owned by digia.

disclaimer: i am just a spectator of open source. i run my laptop with open source os. and i have no experience in coding.

Patch like this would not be acceptable for any serious open source or otherwise project either as it breaks the API. Also open source (not just enterprise) developers would complain about it as they don't want to needlessly change their code either. So either they will need to find a solution that would not break the API (and mostly this can be done unless the API has some fundamental flaws - which is an indicator that it needs to be changed anyway) or they would schedule the fix to the next API breaking release. Enterprise developers can stay on the previous release as long as they want and it will be supported as long as they pay (for extended support they will have to pay extra so they will think twice if they will want to do that).

[Karl Napf]

With Qt5, there is HW acceleration of GUI only with QML/Javascript because Digia want everyone to use QML instead of C++ Widgets. Gap between QML and Widgets is increasing with every Qt release.

My impression is that the QML interfaces are maturing to a point where the underlying C++ APIs are stable enough to be made public. So the gap is actually in the process of closing again, or at least the discussion has started in earnest.

Note that this will not help QWidgets: Their way of rendering is incompatible with OpenGL, so they will not be ported to the scenegraph. There are Qt Quick Components, implementing similar functionality as provided by the QWidgets instead.

[Karl Napf]

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

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;-).

[ulricr]

A primitive example... Code completion has to do something with these? No!
Does code completion make a format better? Doesn't make sense! It's just a textual format. In this case, a textual format with a defined way of representing the data but it's doesn't tell you how to place those tags, because of that you can't really define what "code completion" would have to do for you in this case.

That is completely false.

With XML you define a DTD or XML Schema file that completely defines what is allowed in the XML, and that's what these "code completion" editors use. You're not totally in the dark as what the format is and want values you can set in that "text file".

The code completion is the manifestation of the XML schema.