Does Qt need a modern C++ GUI API?
-
my opinion , every thing z possible with Qt c++
-
Ironically, Digia pledged to support Win8 and iOS while at the same time the first one lacks openGL in metro mode, the second one prohibits V8 from running. And while the Win8 dilemma can be solved by adding even more bloat and dependency by using ANGLE to translate openGL calls into Direct3D, it is obvious that forcing Qt to lean on QML spells more and more trouble, and even worse - exhausting to much developer efforts...
-
[quote author="utcenter" date="1355679123"]Ironically, Digia pledged to support Win8 and iOS while at the same time the first one lacks openGL in metro mode, the second one prohibits V8 from running. And while the Win8 dilemma can be solved by adding even more bloat and dependency by using ANGLE to translate openGL calls into Direct3D, it is obvious that forcing Qt to lean on QML spells more and more trouble, and even worse - exhausting to much developer efforts...[/quote]
Both problems you have listed are already worked upon. ANGLE is default backend on Windows since Qt5 beta1. V8 problem is addressed by v4mv that is under development currently.
Besides, QtWidgets are now back on track with official maintainer.
-
[quote author="sierdzio" date="1355691692"]
Besides, QtWidgets are now back on track with official maintainer.[/quote]Back on track? Which track? Going where exactly? Oblivion?
Maintenance of QtWidgets doesn't change the fact it is morally and technically outdated and no longer relevant.BTW, there is really no need to quote the entire post you are replying to, considering it is the previous one. But then again, if you were that concerned with abstract aesthetics, you wouldn't be such a QML cheerleader ;)
-
V8 "does work":http://lists.qt-project.org/pipermail/development/2012-December/008718.html on iOS.
What has the OpenGL requirement of the scenegraph to do with QML? (Nothing.)
How would a native, non-QML interface change that requirement? (It wouldn't.)Why is it Digias or the Qt Projects fault that Microsoft has made the deliberate choice to leave the industry standard for hardware acceleration out? (It isn't.)
-
Why you ask me questions and then you answer instead of me? And no, I won't answer for you, I am not all that manipulative ;)
Care to point out where exactly did I state that V8 can't work on iOS? IIRC I used the term "prohibit"... Sure, you can jailbreak, but then your application no longer classifies as "legit" in the eyes of Apple. Also, last time I checked, jailbreaking voids product warranty. Apple don't want any execution engines on their platform for security purposes, and a NATIVE API could have plaid a wonderful role here, because it would compile to platform binary, which Apple don't mind being executed on their platforms.
bq. What has the OpenGL requirement of the scenegraph to do with QML?(Nothing.)
QML is an exclusive frontend to using QtQuick2, which is OpenGL dependent. The relation between OpenGL requirements and QML is obvious enough for a blind man to see!
bq. How would a native, non-QML interface change that requirement? (It wouldn’t.)
It depends a lot, a more flexible API could just as well include a fallback for rendering in software, which is not that much of an issue on powerful desktops. This way the same code would be able to run optimally depending on the capabilities of any particular platform.
bq.
Why is it Digias or the Qt Projects fault that Microsoft has made the deliberate choice to leave the industry standard for hardware acceleration out? (It isn’t.)No one argues that MS sucks. The whole point of this "discussion" is to prevent Qt from behaving in a similar manner. Neither Nokia, nor Digia is to blame for the decision of MS to abandon a portable industry standard in favor of their own proprietary technology, but Nokia and Digia are to blame for abandoning another portable industry standard in favor of their own proprietary technology (got to love the hypocrisy of this), I mean of course scrapping a public C++ API in favor of an exclusive QML one. And while MS surely has the downside when it comes to portability, at least its proprietary technology is more capable, more feature rich and offers public native APIs.
See now Lucas - reality extends far beyond your personal conceptual limitations. For some reason you seem to have a huge problem abstracting from your bias and perceiving the matter objectively.
-
[quote author="utcenter" date="1355835060"]Sure, you can jailbreak, but then your application no longer classifies as "legit" in the eyes of Apple. Also, last time I checked, jailbreaking voids product warranty.[/quote]V8 on iOS does neither require a jailbreak in principle, nor does it violate the App Store Terms and Conditions.
The jailbreak is currently required because the used RWX memory allocation scheme is not supported on iOS, but the replacement RW/RX is, which also abolishes the jailbreak requirement.
Apple further on does not prohibit execution engines like V8. The only requirement is that if the origin of the to-executed code is the internet the code has to be interpreted using Apples own execution engine. This does not affect local code and it does not affect QML applications.
[quote author="utcenter" date="1355835060"]QML is an exclusive frontend to using QtQuick2, which is OpenGL dependent. The relation between OpenGL requirements and QML is obvious enough for a blind man to see![/quote]Again, OpenGL is a requirement of the scenegraph, not QML.
A car requires fuel. A car is controlled using a steering wheel. So a steering wheel requires fuel?
QtQuick without QML will still depend on OpenGL. A fully native C++ interface will still depend on OpenGL.
The principal reason for the performance advantage of QtQuick over QPainter and the Graphics View Framework is the state-based, hardware-accelerated OpenGL-based drawing model, called the scenegraph, which is an absolute technical requirement of graphics hardware.
Qt already offers an imperative software- (QPainter) and hardware- (Graphics View Framework) rasterizer. There is no point in creating another.
In addition, the scenegraph requires OpenGL, not hardware-acceleration. It works with any software rasterizer like llvm-pipe in case there is no or limited hardware-acceleration available.
But feel free to share your vision of a hardware-accelerated, platform-independent, high-performance drawing backend (which is obviously not QPainter nor The Graphics View Framwork).
I would love to see my personal conceptual limitations extended.
-
So is there any other API to use the scenegraph in Qt other than QtQuick2, which depends on OpenGL and is exclusive to QML? No? thought so...
bq. What has the OpenGL requirement of the scenegraph to do with QML?(Nothing.)
Leaving QML to be the sole actively developed GUI API mandates the OpenGL requirement. Please don't tell me you still fail to see what is obvious and quite simple. QML is being made a requirement, QML requires QtQuick2, QtQuick2 requires the scenegraph, the scenegraph requires OpenGL. I think about 2 working brain cells outta be enough to figure out how the dependency propagates.
My idea was of implementing a low level graphics API that is backward compatible with a software rasterizer, while stile being able to make use of OpenGL hardware when present. This API itself can be ported directly to DirectX as well, making the entire process transparent, without the need of translators and emulators. QPainter already supports hardware accelerated OpenGL drawing and caching, and the performance is as good as that of QtQuick2, it is just that the process is tedious since a lot of the stuff done for you in QtQuick you have to do manually. All this threat is asking for is a native API that handles all that stuff without forcing QML.
No one can force the expansion of your horizon against your own unwillingness to do so.
-
I think that the developer team must join QtWidgets and QtQuick to make a unique Qml based widgets system, and moving from XML ui files to Qml ui files.
And then map every QtQuick component to C++.
IMHO :) -
[quote author="utcenter" date="1355849576"]QML is being made a requirement, QML requires QtQuick2, QtQuick2 requires the scenegraph, the scenegraph requires OpenGL.[/quote]
-QML- C++ is being made a requirement, -QML- C++ requires -QtQuick- QGraphicsView, -QtQuick- a hardware-accelerated QGraphicsView requires -the scenegraph- QGLWidget, -the scenegraph- QGLWidget requires OpenGL. Therefore the use of -QML- C++ requires OpenGL.
Doesn't sound quite right, does it?
Yes, QtQuick2 requires the use of OpenGL or DirectX for hardware-acceleration, and a software rasterizer if there is no hardware-acceleration available, but this is because of the drawing backend, not the language frontend. QtQuick2 with a native C++ language frontend will still depend on a hardware-accelerated, platform-independent drawing backend, and such a backend will depend on OpenGL (as QGLWidget and QOpenGLPaintDevice does).
[quote author="utcenter" date="1355849576"]My idea was of implementing a low level graphics API that is backward compatible with a software rasterizer, while stile being able to make use of OpenGL hardware when present.[/quote]That's exactly QPainter and the Graphics View Framework, the drawing backend for QtQuick1, which has been deprecated for QtQuick2 because of performance issues.
[quote author="utcenter" date="1355849576"]This API itself can be ported directly to DirectX as well, making the entire process transparent, without the need of translators and emulators.[/quote]The scenegraph drawing backend does in theory support the implementation of a native DirectX backend; but its creation and maintenance is out of proportion with benefit; that's the reason ANGLE is used (and I honestly fail to understand how creating and maintaining a dedicated OpenGL backend, a dedicated DirectX backend and a dedicated software backend instead of a single backend would "...exhaust..." less "...developer efforts ...").
In addition, ANGLE does not only do OpenGL to DirectX translation, it also does GLSL to HLSL translation and automatic shader correction, which results in a uniform, platform-independent application interface. A native DirectX backend would result in platform-dependent application code, as the DirectX shader language HLSL is quite incompatible to the industry standard GLSL.
[quote author="utcenter" date="1355849576"]QPainter already supports hardware accelerated OpenGL drawing and caching...[/quote]Yes, but the problem of QPainter was never missing hardware-acceleration, it was the QPainter API itself.
Again, the principal reason for the performance advantage of the scenegraph over QPainter and the Graphics View Framework is the tight integration with a hardware-acceleration API and the state-based operating principle of graphics hardware, i.e. not beeing QPainter and not providing its abstraction.
The scenegraph moved the abstraction from above the drawing backend (as in QPainter or the Graphics View Framework) to below the drawing backend which made the implementation of a highly optimised, high-performance drawing backend possible.
[quote author="utcenter" date="1355849576"]... and the performance is as good as that of QtQuick2[/quote]No, "seriously":http://blog.qt.digia.com/wp-content/uploads/2011/05/numbers.png, not even close.
[quote author="utcenter" date="1355849576"]All this threat is asking for is a native API that handles all that stuff without forcing QML.[/quote]Yes, and that's an absolutely legitimate request I do honestly support. But you will have to understand that such an API will not change the requirements for the drawing backend and that OpenGL, DirectX, ANGLE and alike has absolutely nothing to do with QML.
-
I honestly don't know why you keep repeating what is obvious and known by all - of course a native frontend to QtQuick2 would require OpenGL, who ever denied that? How many times do I need to clarify I was talking about a hypothetical native GUI API, not QtQuick as it is, but what could have been if it was properly engineered from the start, instead with the idea to make it a tool to propel QML.
bq. QML C++ is being made a requirement, QML C++ requires QtQuick QGraphicsView, QtQuick a hardware-accelerated QGraphicsView requires the scenegraph QGLWidget, the scenegraph QGLWidget requires OpenGL. Therefore the use of QML C++ requires OpenGL.
Now that is just nonsense. First of all - C++ is an industry standard. QML is NOT. Then - C++ does not require QGraphicsView in any way. Therefore it is hardware acceleration that requires OpenGL, and in that context, the best you can say is OpenGL requires C, since it is a C based language, but C++ requiring OpenGL - LOL, just LOL.
FACT IS - QtQuick requires OpenGL, with QtGui it is optional - you have the option, the choice. See the difference?
As for QPainter performance - those numbers are clearly plain wrong. I have done stuff that uses OpenGL QPainter with performance gains up to 2.5x. Don't know if the results from your link were deliberately made as to make QML "shine" or it is a half-ass implementation of OpenGL in QtQuick1, or the test itself was not thorough enough, but I can testify to the fact that with C++, QPainter, OpenGL, some caching and optimizations I get about the same performance boost as QtQuick2 is claimed to introduce, sometimes more.
But if you don't trust me, take a peek at "this video from dev days":http://qt-project.org/videos/watch/graphics-performance-best-practices - obviously the proper utilization of OpenGL can yield significant performance improvement that somehow is magically lacking in the image you linked to.
Again, QtQuick2 makes all those optimizations, which is great, because it saves a lot of work, but it does it in a way that makes QML mandatory, which sucks, since QML on itself rises even more dependencies, not to mention its overheads, and I don't stress performance as much as I stress the extensive extension of custom QML components, which makes using QML a more tedious process than sticking to plain C++. I mean it is not like we can't do our own markup and interpret it, if declarative was of such importance. As for binding - c++11 takes care of that. So why do we really need QML? Because every company out there is itchy to enforce its own proprietary way and isolate the developer base? It was a big mistake to make QML into more than simple markup, I honestly prefer the JSON syntax to the XML, since it is faster and cleaner, but making that into a mandatory language that absorbs the entire development effort of Qt - BAD IDEA. Qt should have moved faster to embrace C++11 instead of sticking to its ancient toolchain, which is the justification for adding JS to the mix. The whole endeavor looks like a clumsy, ill conceived HTML/FLASH hybrid that fails to deliver on its main "selling" points, on top of arriving a little too late to the show.
IMO a portable and more powerful low level graphics API was all Qt really needed, on top of that it is easy to implement different GUI paradigms. One with backends for software, desktop and ES GL as well as DX, with the proper performance or memory efficiency optimizations, that still sets a bar of "common functionality shared across the board" but without excluding more advanced capabilities of modern GPUs.
-
[quote author="utcenter" date="1355915239"]C++ does not require QGraphicsView in any way. Therefore it is hardware acceleration that requires OpenGL...[/quote]Exactly. C++ does neither require QGraphicsView, nor OpenGL. The same way QML does neither require QtQuick, nor OpenGL. It indeed "...is hardware acceleration that requires OpenGL...".
For instance the "Qt Build System":https://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/ uses QML to describe the dependency graph, and does neither depend on QtQuick, nor OpenGL.
[quote author="utcenter" date="1355915239"]FACT IS - QtQuick requires OpenGL, with QtGui it is optional - you have the option, the choice. See the difference?[/quote]If you want to be hardware-accelerated you will have to use OpenGL, be it QtQuick or QtGui - there is no choice. If you don't want to just continue using QPainter, one of the fastest software rasterizer available (or just use QtQuick with a software rasterizer).
[quote author="utcenter" date="1355915239"]... but I can testify to the fact that with C++, QPainter, OpenGL, some caching and optimizations I get about the same performance boost as QtQuick2 is claimed to introduce, sometimes more.[/quote]Use QOpenGLPaintDevice then, the new hardware-accelerated QPainter surface which has been added to Qt5 in addition to QtQuick.
[quote author="utcenter" date="1355915239"]Again ...[/quote]No, not again. All of this has been discussed already.
[quote author="utcenter" date="1355915239"]IMO a portable and more powerful low level graphics API was all Qt really needed, on top of that it is easy to implement different GUI paradigms. One with backends for software, desktop and ES GL as well as DX, with the proper performance or memory efficiency optimizations, that still sets a bar of "common functionality shared across the board" but without excluding more advanced capabilities of modern GPUs.[/quote]I accept that you do not want to understand the difference between the concept behind your proposed solution and the concept behind a scenegraph.
But feel free to join the Qt Project and contribute your "...proper performance or memory efficiency optimizations..." which must have slipped through in the past two decades of Qt and QPainter development and optimization and continue using QPainter, it won't go away.
But don't be peeved if the rest of us leaves this technology behind and is moving on using something different.
-
bq. I accept the fact that you do not want to understand the difference between the concept behind your proposed solution and the concept behind a scenegraph.
You talking about me not wanting to understand - now that's hilarious ;)
Of course there is a big difference, the concept I present is what I as a developer need, and I am willing to bet so do a lot more people.
bq.
But feel free to join the Qt Project and contribute your “…proper performance or memory efficiency optimizations…”So we are back to that, huh? Is there a relation between your ability to comprehend that this cannot be done through individual effort and the amount of times this is being repeated? Pardon my ignorance, but I think it is quite stupid of you to ask me to do what is, in YOUR OWN WORDS, a task too laborious for the big team of people who get paid to develop Qt to bother with.
bq.
But don’t be peeved if the rest of us leaves this technology behind and is moving on using something different.If my eyes do not deceive me, 7 out of 10 people are not happy about that "amazing new technology" and want something better. Not that I am surprised, neither by the complete disregard for the requests of the developer community, nor by the demeaning and insulting techniques, being utilized to discredit and ridicule those requests, in retrospect I realize it was naive of me to consider Qt of such high esteem.
To me it seems like there are people in the management of Qt that honestly believe they know what's best for everyone and have a really hard time realizing their solution is far from amazing and in many regards even far from contemporarily adequate. This kind of corporate behavior has driven the previous company I was employed by into the ground, arrogant executives with poor ideas, amazing in their own eyes, costing about 100 hard working people their jobs.
-
Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api ? After all Qt devs are c++ devs and they will be more comfortable with a c++ api. As a Qt programmer, that is what I feel. Product developers should always understand what the product user wants rather than do what they think is right. So as a customer, I don't share the enthusiasm for Qml. In this fast paced field I'am won't spend time / money with out any clear advantage. We can't learn something just for the sake of learning a new thing. Digia's focus is somewhat different from that of Nokia and now I guess they would have to work on two GUI apis, the QWidget api (which many apps use and are still going to use) and the Qml ones. Double effort. If my logic can be written in Javascript, I will do the UI in Html 5 / css. The designers are experienced in it. So where do Qml fit. I know there are strong supporters for Qml here. But I still feel it was something that was not needed in the first place. May be some important person in Qt hierarchi, may be in Nokia have decided what is good for developers.
-
[quote author="Jayakrishnan.M" date="1355980522"]So as a customer, I don't share the enthusiasm for Qml.[/quote]
You will be pleased, then, than Widgets are maintained again (and, for example, received updates to accessibility in Qt5).
[quote]Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api?[/quote]
Yes and no. Widgets are too rigid and too slow due to complicated layouting calculations. QML works much better here. On the other hand yes, Widgets do deserve more love and will hopefully get it (actually, commit log shows quite a lot is going on in Widgets and Gui).
This whole discussion does not seem very productive, though. The decisions were made several years ago, there is not much point in arguing over that. We are where we are, and are not likely to change the past. Plus, we all obviously disagree and are not very ready to change our minds ;) As for the topic itself: yeah, maybe a new c++ API would be good. It's another big effort, of course, and would mean another API to learn.
-
[quote author="Jayakrishnan.M" date="1355980522"]Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api?[/quote]... and so the cricle is complete to the inital comment I've brought up in this discussion almost ten months ago which is now as true as back then.[quote author="Lukas Geyer" date="1334064028"]I think there is a lot of confusion and insecurity caused by a serious lack of information on both ends, Nokia unable to provide and the developers unwillingly to inform.[/quote]There was never a dedicated explanation on the part of Qt why specific decisions have been made and how they have came into existence - an that's a great pity, because a lot of people felt alienated with good reason; you usually don't support decisions you can't comprehend.
And then happened what had to happen, people either took a defensive position refusing it or an offensive position attacking it - although the most of them obviously have never used QtQuick or are aware of the reasoning behind.
Years have been spent on trying to improve QtWidgets. There was the widgets-ng project, there was the itemsviews-ng project - all of them shared the same result: The way QtWidgets, the layout system, QPainter and as a last consequence C++98 works prevents any significant improvment, and it does not support future requirements of high-performant, hardware-accelerated non-uniform user interfaces. QtQuick is a consequence, not a cause.
People also don't seem to realize that QtQuick does not replace QtWidgets, it is just another option. Noone is forced to use QtQuick if he doesn't want to. QtWidgets is actively developed and maintained and is here to stay.
Should there be a native alternative to QML in the long term? Probably. But I also understand why there is none yet and I fully support this decision.
I still think that there should be an extensive explaination on the part of the Qt Project why QtQuick has been brought into beeing so people who are not willingly to inform themselves can at least comprehend the decision - though I am also realist enough to accept that you can't force people to understand if they don't want to; but then QtQuick is the least of your problems.
-
bq. Yes and no. Widgets are too rigid and too slow due to complicated layouting calculations.
Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?.
I don't know QML is a right choice or not, it is too early to say that
and useless to argue about the decisions of digia, let time prove the
value of QML, wether it is an extremely hot, cool features or notWhatever, digia and nokia have spent a lot of times on QML, it is too
expensive to ask them to throw it away even it really is not a good choice.I repeat, I don't know QML is a right choice or not, but I will give it a try.
-
[quote author="stereomatching" date="1355993261"]Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?.[/quote]
Because QML does exist, is useful and powerful, and this new c++ API is not even planned as of yet? Sure, if somebody starts design/ implementation, I'll fully support it, and probably I'll also try contributing as much as I can. But it's not the case ATM, and even if this project kicks off, it will take years to get to a working stage.
[quote]I don't know QML is a right choice or not, it is too early to say that
and useless to argue about the decisions of digia, let time prove it.[/quote]Too early? It's already with us for 3 years...
-
[quote author="stereomatching" date="1355993261"]Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?[/quote]In a nutshell, binary compatibility, bindings, runtime optimization, network transparency, rapid prototyping and better tool support, extensibility and versatility (as for example in the "Qt Build Suite":https://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/). But feel free to dig through this thread, I think there is not a single argument which isn't in here.
