Does Qt need a modern C++ GUI API?
-
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/
-
And for further detail you might be interested in Alan's comments on the qt development mailing list: http://lists.qt-project.org/pipermail/development/2012-April/003413.html
I think it's a better idea to discuss there, as the discussion will reach more of the developers behind scene graph / qt quick / qml.
-
capisce - Well, this is exactly what the whole point is about - tailoring a nice public API. So a Qt engineer managed to come up with some ugly code to make a biased example of how tedious would it be to use Qt Quick with C++, what a surprise!!!
@QQuickCanvas canvas;
QQmlEngine engine;
QQmlComponent component(&engine);
component.setData("import QtQuick 2.0; Rectangle{}");
QQuickItem* item = qobject_cast<QQuickItem*>(component.createObject());
item->setX(10);
item->setY(10);
item->setWidth(10);
item->setHeight(10);
item->setParent(canvas);
canvas.show();@What about this:
@#include <QtQuick2>
QQuickApplication myApp; // contains engine and surface
QQRectangle item(10, 10, &myApp); // avoid three lines by using that amazing C++ feature, the constructor
item.moveTo(10, 10);myApp.exec(); // shows the entire hierarchy@
And it is not like a contemporary compiler stack cannot hold at least half a megabyte of objects, usually quite a lot more, but feel free to instantiate the item dynamically if you care that much about the significant overhead of dynamic memory allocation:
@QQRectangle *item = new QQRectangle(10, 10, 10, 10 &myApp); // define both dimensions and location in the constructor, why not?@
Although I don't really think this is nessesary, as the class should be fairly small footprint, and resources such as its image cache are supposed to be internally allocated dynamically anyway, since they vary.
I do realize you can make it ugly and you do realize it can also be made too nice for many people to even bother with QML and company, so WTH?
A nice, intuitive public API can reduce that code quite a bit, so instead of those ugly and unnecessary 11 lines we end up with something neat like:
@#include <QtQuick2>
QQuickApplication myApp;
QQRectangle item(10, 10, 10, 10, &myApp);
myApp.exec();@And no, it is not my responsibility, neither is it in my capacity to walk after the entire task force behind the project and make nice public APIs, unlike me you get paid to do that kind of stuff. As I said on numerous occasions, it will take me more time to do it from scratch that patching your messy, undocumented private API. You designed it, you know it, for you and your team it will be tremendously easier to do it, you get paid to do it, you chose not do it the right way right from the start and instead center it all around QML, it does appear to be your responsibility, I am not asking you to come over and do my job, so why do you expect that of me?
As I already said, if you have that much problem designing a neat public API, I am offering my assistance totally free of charge for the collective benefit of all Qt developers, I give you a design for an elegant C++ frontend to Qt Quick, you do the heavy lifting and hide that ugly code in a nice, neat wrapper. Qt Quick gets more public, everyone is happy.
-
Although I dislike temp's provocative style of writing (no offense meant, just my reception) - he (or she? don't know) has a point. I think QML is in fact a very nice additional feature to Qt. I can think of a lot of cases when I would rely on a technology like QML (e.g. it is very easy for a design team to create mock-ups with QML that may be evolved into fully functional UIs) but:
If you provide such a nice and seemingly natively supported feature like QML there should also be an easy way to access these features without actually using a new language but from within the already existing API. There are many development teams out there without the capacity (money or time) to invest into training for QML.
Regarding the "it's open source - so just contribute"-point I saw mentioned in this thread: Just because you may contribute content to a repository it does not mean somebody with a good ideas has the required abilities/time/... to do so :)
-
bq. As I said on numerous occasions, it will take me more time to do it from scratch that patching your messy, undocumented private API.
Since you again ignored the part of my earlier that pointed you at the current private API, here's a direct link: http://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/quick/items/qquickrectangle_p.h
It won't be made public for Qt 5.0, but nothing's stopping you from trying out that API, or writing an add-on that exposes it. Just be aware that it comes without SC / BC guarantees.
Alan on the other hand was offering an alternative that would be SC / BC, and of course it's a bit more tedious, but you could in theory write your own C++ wrapper around it, exposing it with a nicer API. Just because Qt doesn't offer everything straight away doesn't keep you from writing a little bit of extra wrappers in the short run.
-
[quote author="Daniel Eder" date="1335181849"]Regarding the "it's open source - so just contribute"-point I saw mentioned in this thread: Just because you may contribute content to a repository it does not mean somebody with a good ideas has the required abilities/time/... to do so :)[/quote]
If nobody has the required abilities and time to do so, then it won't happen. In fact, it's not about the abilities or the time. It's about the financial investment of developing and maintaining the Qt codebase. And frankly, I don't really understand what we're hoping to achieve here.
Even with open source, there's no free lunch as they say, and Qt developers are only that, paid developers. If none of the major contributing employers (Nokia for the most part, but also Digia, KDAB, Accenture, Intel...) judge it interesting to invest in a C++ API, then it's indeed unlikely to become a priority anytime soon.
It's a meritocracy where Nokia happens to be the party investing the most, but luckily, it's no longer a closed group. So if there is another company out there that wants to pay several full-time devs to work their way up to a contribution point where they are part of the decisional level of Qt, then what's stopping them? Just don't expect other companies to pay for something that has obviously been judged not a priority for them. I know it sounds a little cold, but I think that's really all there is to it.