Does Qt need a modern C++ GUI API?
-
I appreciate the work done by Qml developers. They have done very well what they have been told to do. And I don't have anything against Qml. But I have voted for a purely c++ UI api, because I'am a c++ developer and it is more comfortable for me to do things the C++ way.
For people who think c++ is not the right tool for fluid GUIs, on the iPhone we do all the UI stuff in plain Objective-C. So why not C++. So any argument that a declarative language is needed for fluid and flashy UI is simply not true. And not all mobile apps need a flashy UI. Qt developers are C++ developers. A vast majority of them have no experience in html / css / Javascript. I was surprised that instead of enhancing the existing QWidget api which the c++ devs are familiar with, a new declarative language was developed. This along with some heavy promotion of Qml on the blogs are responsible for some misunderstanding regarding Qt support for C++ in Qt 5.0
Comments like ' It is expected that entire applications would be written in js / Qml without c++ ' only helps to create confusion. If I can write my the entire logic in JS, I would prefer HTML5 for UI. Again on some other blogs there are some people who have created applications using Qt quick and what they highlight as the important point is that they don't use c++. We can't blame people, if, after seeing all these, they doubt Qt's commitment to C++.
-
Before going further, I should first qualify my experience. I have not used QML for anything "real". I have only gone through the tutorials and examples provided in the QT documentation. Based on what I saw, I did not feel the need or desire to learn the QML/QtQuick way of doing things.
From what I understand based upon this minimal experience, I am puzzled why the choice was made to move forward with a different language solution first before first establishing a proper use model and conceptual API in C++ first.
From reading various posts on numerous threads, my understanding is that the primary guiding reasons to create QtQuick1, QtQuick2, and QML were:
- The "procedural"/imperitive paradigm of the QWidget painter architecture was not scalable to hardware acceleration. Thus the need for a way to "declaratively" describe a UI so that the underlying implementation could optimally map it into availabel graphics hardware resources
- There are various visual effects that are difficult or infeasible to do in the QWidget architecture
- QWidget and QGraphicsItems sometimes had performance problems that were intractable without moving to a different architecture
- There was the perceived need to more rapidly create UI's using a specialized textual language that was somehow better suited to this task than C++ code using QWidgets/QGraphicsItems. It was felt that such a textual description would be more usable by "designers".
- There was the perceived need to be able to use an interpreted description in order to provide fast iteration of changes in the UI. In addition to this, some also felt that this architecture would allow for network transparency.
- There was a perceived need to be able to avoid making binary compatibility guarentees.
I hope the above list is mostly inclusive of the true reasons. Perhaps, someone with more knowledge can help us understand other reasons that went into the decision process.
Items 1-3 seem to be performance and/or architecture related and have little to do with the exact method used to formulate the description of the UI. Items 4-5 are mostly related to how to describe the composition and behavior of the UI to the underlying graphics system. Item 6 is more related to logistics of providing a complex framework to a wide variety of users.
I don't believe there is any argument by user "temp" and others that Items 1-3 are important and need to be addressed in some way to keep QT up-to-date and modern.
Regarding the choice to create QML to address Items 4-5, as user "temp" has talked about in this thread as well as several others, there appears to be little that a special purpose language (QML) can provide that a properly structured C++ API could not. If you look at the currently available documentation on all the QML elements, the documentation looks remarkably similar to what you could/would provide for a C++ based implementation of the same elements. There is a list of "properties" and a list of "methods". Obviously, C++ classes can easily support "properties" and "methods". Embedded JavaScript provides procedural functionality that can just as easily be provided by C++ statements. Slot handling could be handled in a straightforward way by function objects or lambda functions (a C++11 feature admittedly). A properly working "make" system could quickly build a new C++ based UI in a few seconds or less, so the interpreted language argument is not convincing. Even network-transparency would appear to be a solvable problem using a serialized version of the resulting data structures.
(continued on next post)
-
(continued from an earlier post)
In addition to providing duplicate functionality to what C++ could provide, creating and supporting QML has some significant downsides. These include:
- The requirement to learn a new syntax (QML)
- The user requirement to learn a new set of QML elements. Not that this wouldn't need to be done for an equivalent C++ implementation, except that C++ versions of these elements would probably closely mirror the QWidget versions.
- The requirement for a new parser for QML
- The requirement for a Javascript interpreter (apparently V8 in Qt5) with the concommittant requirement of porting and support. Moreoever, it appears that using V8 could preclude Qt's use in iOS - maybe this has changed, but I had heard this somewhere not too long ago.
- The runtime and memory overhead of the QML interpreter. Some may argue that this is very little. Some would argue that it is significant. I haven't seen concrete data one way or the other. In any case, there's no question that the runtime and memory overhead are > 0.
- A more complex build environment that can understand QML files and their inter-relationships and dependencies.
- A larger and more complex QT distribution which is harder for the open-source community to understand and contribute to.
- The opportunity cost of developing all the QML infrastructure. That is, the engineers who did all the QML specific development were not available to improve other areas of QT.
The best argument that I've seen to date about the utility of QML is that it allows the QT developers more freedom to change the underlying implementation (in C++ of course) without incurring the binary compatibility problems that can come up with C++ API's. But even here, it would seem there are several alternatives. One is that a high-level C++ API could be provided along the same lines as the currently available QML elements. These high-level API's could use the same compatibility mechanisms as have been successfully used in Qt4.X for many years. There could also be a statement to the effect that if you want to use the mid and low-level API's (scene-graph and GL stuff) that these might change and there will be no guarentees of source or binary compatibility until some future time.
Somewhere in this thread or one of the others, temp/Dian made a "challenge" to the community at large to come up with specific use-cases of QML that they perceived provided significant benefits that C++ implementation of the same could not provide. I believe this is a valid challenge that the architects of QML and others who are highly "pro-QML" should attempt to do, if for no other reason, than to satisfy themselves that QML really is providing significant benefits above and beyond what a straightforward C++ implementation could provide. temp/Dian also volunteered to help define a streamlined C++ way of doing things, if only he were provided examples of things where QML was perceived to provide value. And these sorts of examples would go a long way to quieting the growing contingent that appears to be unconvinced of QML's utility.
All in all, my current opinion, as controversial as it may be, is that the management of QT made a serious mistake at least in the order in which they developed/released the new GUI functionality. They should have first defined/developed a C++ version of the GUI API. Then, once that had been developed and at least some experience developed with it, then QML could have been developed to address the other segments of the user-base which still deemed QML to be important.
-
Because question is asked as is I voted for: "No ..." .
I know that QML is slower but it is more elastic and UI can be done faster in it.
I don't know Apple graphics something ... framework which was mentioned few times here, so I don't have whole view on the issue, but for my needs QML is enough.However I find reloading of a table, containing many many elements, done this way a little bit "slow". Off course "slow" is as always relative to user experience and expectation.. :)
@
Grid {
id: measTableGrid
rows: tableViewModel.tableModelData.tableRowsCount
columns: tableViewModel.tableModelData.tableColumnsCount
Repeater {
model: tableViewModel.tableModelData
delegate: MeasTableDelegate {
width: isFirstColumn ? 2*UI.FONT_SIZE : tableViewModel.tableModelData.standardWidth
model: tableViewModel.tableModelData
}
}
}
@ -
I think there are probably a number of people who would be willing to contribute to the C++ API if only there were a bit more documentation or examples available.
For example, perhaps, some set of people might be interested in putting together C++ classes that mirror the currently published QML elements. The problem is that at least for some of these, it is difficult to know where to even start. If one of the current developers could perhaps create an example of what a C++ API class could look like and an explanation of how it interfaces to the lower level API's then some volunteers could get started looking at this example and actually make some progress.
As it is now, the code base is simply too intimidating for anybody outside of the main developers to really do much with. Can any of the developers comment on whether any sort of examples (at a minimum) could be made available?
-
bq. From what I understand based upon this minimal experience, I am puzzled why the choice was made to move forward with a different language solution first before first establishing a proper use model and conceptual API in C++ first.
Geez, you know how many times I've asked this question in numerous forms and never got even a remotely reasonable answer. Only denial that the one logical answer, pushing QML ahead, is not true at all. Also the sky is not blue and water isn't wet. Why does Apple make software that only runs on its platforms, when the platform is x86 and supporting Windows or Linux will likely result in more sales of the actual product, but sadly less sales of of MacOS and Mac machines. Why do big companies develop amazing and powerful APIs using C++ and then lock native use away and present those APIs for exclusive use through their own, proprietary language, even thou it is usually inferior in terms of flexibility and performance. Sure, C++ is more complex and potentially more dangerous, but providing an additional, easier language plus C++ access is the right thing to do, so developers can chose what they want to use according to their needs and preferences, so the extra exclusive features are given to their own languages simply to enforce them, fragment an already fragmented beyond the reasonable developer base, just to get more foothold by depriving people of choice and conforming them.
bq. the management of QT made a serious mistake
Either that, or I am correct and it is not a mistake but their plan right from the start.
As I've already said, if the Trolls did the right thing right from the start, things would not even come to this ugly and absurd situation. And I have a very hard time assuming a long time and dedicated programmer will skip on the right thing to do because it would be right to do it, I understand their motivation for QML but I don't understand their motivation for the exclusivity of features, available only through QML, especially when nice public APIs to Qt Quick and the SceneGraph will only make them more extendable, something which even QML users will benefit from.
One thing for sure, Nokia should be quite pleased with all the fanatical devotees who pick up on their decisions and blindly promote them "the one and only right way, right for everyone" with everything else being wrong, useless and so forth. I am surprised how many people welcome the absence of choice and think it is best for everyone to be conformed to decisions made for them without accounting their actual needs and continuously ignoring their requests. When I started learning Qt I did so because I assumed it is a framework, focused on native C++ development and improving on it, if back then I knew it comes closer to a toy app, unnecessary API cult, whose vision of the future is an arriving late to the show imitation of what other companies have done for years and many are currently walking away from, I'd never waste all that time on it... I honestly cannot appreciate a form of community where other community members want me and many others deprived of choice and conformed to choices made for us that don't really make us all that happy.
-
-
This poll has no value. Regardless of who is right or wrong, the wording is completely partial to making QML look bad, and the entire discussion seems to be a contest about "who can shout the loudest".
If you're unhappy that the project leadership does not share your views, and if you really want a C++ API, just take a good look at the Qt sources, and write an API...
I only started familiarizing myself with Qt internals a couple of weeks ago, and it's not such a big deal. Agreed, it takes some effort to learn a new logic, but from what I read, many seem to be very skilled an experienced in C++, so why not put that to good use instead of complaining. -
temp, you could be right, but I'd prefer not to speculate on intentions. I'd rather just focus on the technical arguments. Over the course of your arguments on various threads, and through my own knowledge, I've come to believe that your points about the need for and benefits of a C++ based API are almost a forgone conclusion.
Every argument I've seen put forward by pro-QML anti-C++ come down to one of a few things:
- Making C++ API is too much work. Better to put that effort into more QML.
- Don't want binary compatibility guarentees when in this early mode of experimentation and development.
- Why would you want to use C++ when QML is sooo much simpler. Just try it. You'll like it.
- What's the big deal. Overheads are so small as to be negligable.
The counter arguments against these are simple and have been made many times. But for whatever reason, no on will acknowledge the counter-arguments. And no one will actually present any facts to back up their point of view.
-
@pierrevr. Perhaps you could create a writeup that shares the knowledge you've been able to acquire about QtQuick2 internals through your familiarization of the source code? I'm sure there are any number of people who could use that knowledge as a kickstart to their own familization process.
-
I mean, it is so OBVIOUS all those decisions were made to pave the way for issuing statements like:
bq. "QML is a requirement for modern GUI"
A data structure describing language a requirement for GUI? Damn it, and me, the stupid one thought it was a modern, hardware accelerated backend that was the requirement, SILLY ME...
It could have been any other form of text just as well. QML is as much a "requirement" for modern UI as SVG is a "requirement" for vector graphics or XML for only god knows how many things. It's just foolish.
@minimoog77 - thanks for bringing those cliches to my attention, It is only the n-th time I read such insightful clarifications that manage to miss all the points all over again:
bq. .ui files in Qt 4.x are XML, yet nobody complains about these.
Missing the point - because you were still free to do it in a programmatic, imperative way besides a descriptive, declarative way. AND THE ONLY GLUE you needed to access XML defined UIs was a single ui pointer, nothing like with QML. Unlike QML, XML was not MADE a requirement, it was an option, the usage of which brought none of the drawbacks of QML. And wherever you chose XML or doing it the old school way, you still got the same backend, same features, same performance, unlike with QML.
bq. Simply exposing the C++ interface of all QML elements won't buy you anything, as the most important feature of Qt Quick (bindings) still can't be handled that way.
Missing the point - because what people want is a public API to use the new backend, not a C++ interface for QML elements, just give us a nice and well documented API and we will make our own components, people want access to the C++ backend, there is no need to carry the burden of interfacing all QML centered stuff to C++
bq. If you need to create your own QML elements in C++ we have QQuickItem and QQuickPaintedItem, which form a very good and solid basis.
And those help us avoid QML how? Oh, wait, it doesn't!
bq. That's a strongly biased poll due to the wording. And it's missing the points the Lars has been trying convey, but some seem to ignore.
It is Lars who is missing the points, thus the disagreement with his points which do not account for the points, we don't ignore Lars' points, we are well aware of those already.
bq. This poll has no value. Regardless of who is right or wrong, the wording is completely partial to making QML look bad
I am happy you can disregard the needs of so many people with such a light hand. My question to you is whether any of those words, used in the poll is not true? Isn't QML extra syntax, doesn't it require an interpreter, doesn't it require JavaScript for basic stuff like property binding, doesn't JavaScript require a virtual machine, doesn't the limitations of QML require glue code and glue objects to extend with C++??? Which one of those are partial to making QML look bad, I didn't even hint to those being bad, just presenting them as the full entourage that comes with QML, which may not be familiar to some people who only know QML in the form of a few snippets of rectangle objects. We've been presented with the benefits of QML on countless occasions, I just focus on the drawbacks just to make it even, and I don't even present them in a negative way that states those do not need to be, but in a way that states those should be OPTIONAL.
And furthermore, do you really think people are that stupid to be fooled by my treacherous, cunning and deceitful use of words? LOL
bq. If you’re unhappy that the project leadership does not share your views, and if you really want a C++ API, just take a good look at the Qt sources, and write an API…
I only started familiarizing myself with Qt internals a couple of weeks ago, and it’s not such a big dealWhy don't you do it then, when you find it that easy? You will have the gratitude of so many people?
bq. temp, you could be right, but I’d prefer not to speculate on intentions
I prefer the same, but if we are given nothing more, what else are we left with? Speculation is always a last resort in my book.
-
".ui files in Qt 4.x are XML, yet nobody complains about these."
This isn't count!
I have used the Qt from version 3. At that time the Designer wasn't so reliable, and its knowledge run behind the full API.
So, I used Qt always from scratch: only in C++ (*.h and *.cpp).
I know, today the QtCreator much more clever than before. But I use no the designer in the IDE. I follow Mark Summerfield (author of the official Qt book!) technique, building projects only from cpp source code. -
bq. Simply exposing the C++ interface of all QML elements won’t buy you anything, as the most important feature of Qt Quick (bindings) still can’t be handled that way
Can someone please explain why the above statement is true (or not)?
-
@broadpeak: My point was, agreeing with mlong, that the poll isn't even closely neutral enough.
Just to clarify on my views... Although I am generally fond of native code, I believe QML is a good approach to UI. But seeing the discussion, "who can shout the loudest" still comes to mind and, respectfully, I will go back to my work.
-
With regards to "who can shout the loudest". What other choice does one have at this stage if one isn't able to "do it yourself" and there is so much inertia and false information in the system due to years to promulgating the "goodness" of QML and years of developing QML by dozens of engineers.
-
The one thing I honestly don't get is why are some people acting like I am the devil's advocate and that I am standing for some evil cause what will somehow be harmful to people?
Since when is the option of sticking to C++ and offering your users the most efficient solution at the expense of a little extra work a bad thing?
Can somebody perhaps answer?
-
[quote author="c++freeloader" date="1335165426"]
For example, perhaps, some set of people might be interested in putting together C++ classes that mirror the currently published QML elements. The problem is that at least for some of these, it is difficult to know where to even start. If one of the current developers could perhaps create an example of what a C++ API class could look like and an explanation of how it interfaces to the lower level API's then some volunteers could get started looking at this example and actually make some progress.
[/quote]Seems both you and temp ignored my previous comment, where I pointed to the C++ API exposing the QtQuick items: http://qt-project.org/forums/viewreply/83016/