Does Qt need a modern C++ GUI API?
-
[quote author="broadpeak" date="1334990942"]
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.Wrong tool.[/quote]
What??? :):):)
Every serious software is written in C++, even the QML and JavaScript interpreter too.
A lot of (if not all...) high-level programming language compiler is written also in C++. The very new Win8 is written native C++ too. The Android and the iOS are written also C/C++.
An so on...[/quote]The thing here is that C++ is a great language for all the heavy lifting that should be performed in the back-end. And QML is great to develop fluid and visually attractive front-ends.
So I my self have to agree that QML is a far better tool for the GUI, witch does not prevent you from performing most of the core operations using C++. That's actually a more modern and maintainable way of writing software if you ask me.
I think I shouldn't have to convince anyone that having your code neatly separated into a portable back-end and possibly multiple easy maintainable front-ends is a good thing.
Don't get me wrong I love C++, but some times having your entire application written purely in C++ is like firing a cannonball at a fly. Sure if you aim it properly you'll get to hit the fly and it's going to be spectacular, but than aiming it at a different fly will take far to much time and effort to be effective. (I know this is very exaggerated) (does “CODE LESS DEPLOY EVERYWEHERE “ ring a bell)
@temp you are wasting far to much energy on this (and sorry I have far better things to do than read your ... long posts write a blog or sth.) And IMHO Qt + QML is way better than what WP7 has to offer, so you're wrong when requesting Qt to be "a tiny bit better" when it's a hell of a lot better. Also if you think Qt is missing something no one is stopping you from contributing (IT'S OPEN SOURCE).
-
@temp: Have you even given the C++ API a try by using the private headers in QtQuick? Sure, for a couple of Rectangle and Text elements in a hierarchy you can do that easily from C++, but once you want to define custom behaviors, states, animations, and bindings it's just so much more convenient in QML that I believe many of the people who are asking for the C++ API would end up using QML in the end after all.
bq. with QtGui everything you can do in the designer or with XML you can always do in C++
The difference from XML and HTML 5 is that QML is very readable and pleasant to use even from a stand-alone text editor. Noone is forcing you to use Creator.
-
@kkrzewniak - as a tool, dedicated to GUI structure and design description, QML is the easier to use tool, there is no arguing here. The same applies to training wheels, it is surely easier to drive a bicycle with training wheels if you are new to it, but if you can drive a bicycle without training wheels already, then those become a limitation instead of а facilitation.
@capisce - No, I haven't, I don't know the internals of Qt Quick. If you don't mind, please do get a little more technical concerning techniques that will not be possible to do in C++, I am honestly curious. Property binding - I don't see an issue here, attaching states and animations - it depends on how is this actually implemented in the backend, something you could tell me perhaps, since finding out myself will require quite a lot of digging through a not exactly easy to read API. If it is done in the spirit of Qt, then I don't think it is that hard creating a state instance, attaching it to a parent, setting up and pointing it to the properties it needs to modify and connecting some signals and slots. No rocket science at all. Maybe a little harder than doing it with QML, but potentially a little easier (for programmers) since some of the work can be done in the very constructors of objects.
It all depends on how would an eventual C++ frontend will be designed. If out of spite for being forced to do it, your team decides to make a half ass job just to get it back at us, then sure, it has a very good chance of being too tedious to work with, and achieve a purpose it was designed with - to convince us QML is better. But I can also imagine an elegant way to do it, one that will make QML pointless for many people, which I don't think your managers are too keen on.
Surely, making it nicely fit with a C++ frontend MIGHT require some reworking, but it is your fault for not building Qt Quick with the idea of native usage from the ground up. Seriously, who writes an API in C++ without considering the most obvious option of using it natively? Someone, looking to enforce their own "language" for sure, but who else?
I cannot do a C++ frontend to Qt Quick myself, but I am willing to contribute to it whatever I can, and since I notice you as well as other people claim some stuff is not doable, perhaps I will be able to offer a workaround for those cases? Just post a QML snippet, accompanied by eventual backend catches that would make it hard to do natively, if there are such, and I will do my best to propose an elegant solution.
///
So what you want to tell me the main purpose behind the invention of QML instead of using already established and widely used standards is so that you can use Notepad for programming? Heck, there is a ton of text editors that support XML/HTML syntax highlighting and structuring out of the box or through a few clicks away downloadable extension, and I don't buy it that QML is any more readable than HTML, maybe to you, a person who has extensively used and potentially designed QML and may not have used HTML that much at all, but objectively it is about the same... Sorry but I am totally giving the edge to HTML+CSS, it is much more flexible, it is much more widespread and supported virtually everywhere.
I chose Qt for its ability to deliver applications in native code, and it makes sense I want that feature being improved on rather than being left just for compatibility purposes. If I wanted to lean on something like QML, I'd never bother with Qt, I already know HTML and JS, so I am good to go with trivial apps that will be supported on every major platform out there.
-
Qt has a had a C++ API for animations and states for some time, see http://doc.qt.nokia.com/4.8/qabstractanimation.html and http://qt-project.org/doc/qt-4.8/qstate.html
Behaviors in QML is simply an easy way to bind an animation to property changes: http://doc.qt.nokia.com/4.8/qml-behaviors-and-states.html
As for the QtQuick internals, see src/quick/items/qquicktext_p.h, qquickrectangle_p.h, qquicklistview_p.h etc. There's your C++ API, and you're free to use it as long as you accept that it's private API and thus offers no source or binary compatibility guarantees. I guess it could in theory be polished and made public if there is enough interest, but for that to happen it might be useful if people give it a try and offer feedback. I haven't tried to use these existing items from C++ myself, but I have made custom C++ QQuickItems for use with QML. I don't think the reason for not offering a C++ API from the start is malice, but rather a lack of resources and (until now) request.
An XML-based syntax was initially considered for QML, but dropped in favor of the more readable JSON-like syntax. HTML has a lot of legacy cruft, and no good support for animations and transitions without using WebKit specific extensions and such, and from what little I've seen the syntax is not ideal. I think most people using QML would not prefer to use HTML.
-
[quote author="cincirin" date="1334963428"]Nobody said that QML is not perfectly suited for it. Question is why Qt not follow the successful Apple native sdk policy. Or ... are Apple "iOS Graphics and Animation":https://developer.apple.com/technologies/ios/graphics-and-animation.html or "Mac OS X Graphics and Animation":https://developer.apple.com/technologies/mac/graphics-and-animation.html perfect native development kit ?[/quote]
What is the definition of native? For example is Angry Birds native? But if somebody told you that Angry Birds is using Lua for scripting then maybe it isn't? :)
Anyway, I am looking at this QML scaaaary thing like this:
You have a 2D/3D rendering engine which is optimizing the rendering on the GPU (scene graph). Written in C++. You can also add your own nodes (rendering yourself) if you want.
On top of that you have some kind of scripting language which defines the 'scene'.
Heh, it's like any modern game engine. :)
Also, you have easy (not perfect) access from scripting language to 'native' C++ objects and vice versa. Nice. So you don't need to write IDL. :)
-
[quote author="temp" date="1334993354"]C++ cannot describe UI in a declarative, structured way, nobody claims that, ...[/quote]
(just pulled the last quote regarding C++ and UIs, not replying to that post)
C++ is very capable of creating UIs in a declarative way, it is just that QWidgets are not implemented with that kind of API. One could create an API that would allow this to be a valid C++ code:
@window (
name = "winMain",
button (
name = "buttonBig",
size = parent.size,
title = "Click me!",
onClicked = something
)
)@--
p.s. If a "modern GUI" can be done in HTML+JS, it can be done in anything :) -
@capisce - I have really grown tired of hearing all the same clichéd arguments over and over again, having to explain what is wrong with them over and over again, especially since the people who present those know DAMN WELL what's wrong and needs improvement.
Point of the matter is - you can all read numbers, this poll started at a 2-to-1 ratio and despite being dug down in a place with plenty of Qt community members and their inevitable, even if unintentional bias, the poll is steadily moving towards a 3-to-1 ratio. Since you are a programmer, I assume you are good with numbers, and it does seem to appear it is not a minority but a majority of people who call for an improved, native C++ GUI API that meets today's standards. And with all that bragging about Qt's community, I think it is only natural for you to pay some attention to what your developer base wants instead of convincing everyone in the opposite.
@minimoog77 - no one is scared of QML, just for lots of people it is not needed, and having to use something you don't really need to use just so you can get access to an improved GUI backend is..., well, just stupid. The word stupid might not mean a lot to someone, whose idea of a shining example of an application is Angry Birds, but again, looking at the poll results so far it would appear over 2/3 of Qt users share my opinion. We cannot all be impressed by Angry Birds, no matter how successful it may be for a wide range of very sad reasons.
-
[quote author="temp" date="1335005392"]@kkrzewniak - as a tool, dedicated to GUI structure and design description, QML is the easier to use tool, there is no arguing here. The same applies to training wheels, it is surely easier to drive a bicycle with training wheels if you are new to it, but if you can drive a bicycle without training wheels already, then those become a limitation instead of а facilitation. [/quote]
No QML is not like training wheels, you use training wheels while learning how to ride a bike. By stating this you imply that QML is used by people that do not have the skills needed to code up a GUI using pure C++, when it's clearly not true. It's widely used because it greatly reduced the apps "time to market".
Don't get me wrong I do understand that there are use cases that require code written purely in C++. But to me you just sound like one of those guys going on about how Assembler is so much better than C/C++ and every real programmer should only code in Assembler.
And again Qt's code does not come into being by it's self it's a fruit of the Trolls hard and on going work (pleas respect that), and even Trolls aren't supper heroes and their man power is limited. The thing that gets me the most is that you go on about how it's all bad and yet fail to see that you could redirect some of that energy into actually contributing something to Qt.
Granted you're very good at making noise.
-
No, I don't think assembler is better, yes it is faster, but it is different for every platform and it is not applicable unless you are writing something really low level like a compiler or a short performance critical routine.
You just took the training wheels analogy too literally, I didn't use it in full parallel to QML, even thou people that are new to programming can use QML and achieve some eye candy which will not be possible for them with C++ right away, I do realize experienced developers might also want to use QML for time saving and such. I still think with the right native frontend, coding a Qt Quick application could end up faster for various reason besides not needing to design with the limitations of QML in mind and glue custom C++ objects.
I do respect the work of trolltech, that is part of the reason I feel so bad about the direction Nokia is pushing things ever since the acquisition. Me being critical has nothing to do with disrespect. I am just the type of person who cannot force himself to praise with admiration actions that I don't find adequate.
-
[quote author="temp" date="1335011895"]
@minimoog77 - no one is scared of QML, just for lots of people it is not needed, and having to use something you don't really need to use just so you can get access to an improved GUI backend is..., well, just stupid. [/quote]
No it's not. If you want static UI, QWidgets is enough for you. But once you start animating, it's not. Then you go to QGraphicsScene, but you will end with lot of micromanagement.QWidgets will stay. QGraphicsScene will stay.
You have you choice. Nobody forcing is you to use QML.
[quote]
The word stupid might not mean a lot to someone, whose idea of a shining example of an application is Angry Birds, but again, looking at the poll results so far it would appear over 2/3 of Qt users share my opinion. We cannot all be impressed by Angry Birds, no matter how successful it may be for a wide range of very sad reasons. [/quote]
Angry Birds it's just an a example of using C++ with combination scripting language. It's natural thing to do. -
QML is a cool way to write simple UIs, but it just doesn't fit every developer needs.
- it has an overhead
- It just doesn't scale up well, would you really port a complex interface using QML, for example blender?
- It doesn't report common mistake that compilers usually reports (especially clang is making huge improvements in this field)
- You can't do any static analisis (which is really useful and it's improving)
- It's LIMITED, you can't do a lot of stuff using QML (for performance reasons), you need to create a plugin for each "strange thing" you want to do which lengthen times A LOT
- It's not portable, as many developers reported, HTML+CSS is much more portable and easier (for web designer too)
As i see it, QML is NOT USEFUL(it's replaced by HTML+CSS/json), the only context i can think of is Symbian and few simple applications.
As a project manager i won't use ever use QML, as i see it now, it's just a toy. -
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.