Does Qt need a modern C++ GUI API?
-
I do. And if you would have followed the discussion you would have seen that I've never had a problem with people demanding it, but rather how the gave reasons; and you would know that I've explicitly mentioned that Qt should have a native QtQuick API.
But I do have a spot of bother with it, and it is to be feared that your are most probably not amused with it, as it is quite of a killer argument: it is practically impossible to express the requirements for such an API in C++98.
But I'm quite sure you bring an idea, a sketch, a paradigm or possibly even an early implementation of such an API with you, which supports at least automatically re-evaluable expressions, or bindings as you call it, which substantiates your demand and in further consequence disproves my assumption, don't you?
-
[quote author="d3fault" date="1336928933"]Hardware Accelerated C++ GUI API with bindings does not require a JavaScript Interpreter, a Virtual Machine, or a brand new declarative language.[/quote]
It does not theoretically "require" them, no. But then again, no computing task theoretically "requires" anything more high-level and productive than assembler code. And not even that, why not go one step further and design a new hardware chip for each computing task?
Yes, there would have been different possibilities for solving the task that QtQuick/QML tries to solve. The Qt developers made a design decision. They gave higher value to maximizing productivity for application developers/designers, than to making diehard "C++ for the sake of C++" purists happy. A good choice.
-
[quote author="jdavet" date="1336997353"]They gave higher value to maximizing productivity for application developers/designers, than to making diehard "C++ for the sake of C++" purists happy. A good choice.[/quote]
Wrong. They gave higher value to creating a NeW eXtreMe eXper1mentaL "Designer Friendly" AppLiCatiOn pr0gr4mming LaNguaGe in hopes that it would earn them more moneys in the mobile market. They're pissing a lot of us C++ devs off by forcing the use of this NEW BITCHIN PROGRAMMING LANGUAGE [if we want to use up-to-date UI]. We already know how to code and we don't need a javascript interpreter thank you very much.
If I was a C++ purist I'd be using Boost, not Qt. Qt's use of MOC makes C++ purists cringe.
[quote author="Lukas Geyer" date="1336990448"]But I do have a spot of bother with it, and it is to be feared that your are most probably not amused with it, as it is quite of a killer argument: it is practically impossible to express the requirements for such an API in C++98.[/quote]
I agree. A lot of the previous examples included the use of lambdas and C++11 features. Here is one that is C++98.... though it is uglier because of it. (best case scenario: support both)
What you type:
@m_SomeDeclaredView.somePropertyToBeUpdatedWhenTheBindingPropertiesChange = Q_BINDING((Q_BIND(m_SomeOtherObject.someProperty1) + Q_BIND(m_AnotherObject.someProperty2)) /Q_BIND(m_YetAnotherObject.someProperty3) + aConstantInteger);@Post-MOC result:
@
//Auto-Generated
autoGeneratedEvaluateFunction()
{
return (m_SomeOtherObject.someProperty1 + m_AnotherObject.someProperty2) / m_YetAnotherObject.someProperty3 + aConstantInteger;
}
connect(m_SomeOtherObject.someProperty1, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());
connect(m_AnotherObject.someProperty2, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());
connect(m_YetAnotherObject.someProperty3, SIGNAL(changed()), this, SLOT(autoGeneratedEvaluateFunction());//Your original binding, wherever you typed it
m_SomeDeclaredView.somePropertyToBeUpdatedWhenTheBindingPropertiesChange = autoGeneratedEvaluateFunction();@in the precompiler stage,
each Q_BIND evaluates it's contents to ensure it is being pointed to a proper Q_PROPERTY
each Q_BIND 'makes note of (somewhere)' the property it points to
the contents of Q_BINDING are stored in some "autoGeneratedEvaluateFunction" function, with the Q_BIND macros removed (since we've already processed them)
the right hand side of the equals sign points to autoGeneratedEvaluateFunction() to get the initial state
each of the Q_BIND'd properties we 'made note of' have a slot connected to their NOTIFY Q_PROPERTY signal. this connection is disconnected when the view is no longer seen.
the slot that the NOTIFY signals is the autoGeneratedEvaluateFunction function. there could also be some: if(new != old) { old = new; emit changed(); } protection in the property's setter.since aConstantInteger is not surrounded by Q_BIND (and since it's constant!), there are no signals/slots to set up. Q_BINDING might (idktbh) also need compiler optimization-prevention so it doesn't get rid of aConstantInteger
I pulled this example out of my ass. I'm sure others could come up with a better solution. Do you also need to be shown how to declare a GUI in C++?
[quote author="jdavet" date="1336997353"]It does not theoretically "require" them, no. But then again, no computing task theoretically "requires" anything more high-level and productive than assembler code. And not even that, why not go one step further and design a new hardware chip for each computing task?[/quote]
Any solution is not the best solution. Qt strives for the best solution. There are plenty of overly expensive languages that provide the exact same functionality as Qt... usually incurring a run-time cost (JIT etc) where Qt requires none. Java/.Net/any-interpretted-scripting-environment... are all inferior to Qt.... for the same reasons QML will be inferior to a Hardware Accelerated C++ GUI API with Bindings: Native and/or Not Interpretted. (give me QML compiled down to byte code in my executable and don't force the use (includes simple loading without using (a lot of people saying: don't like js? don't use it!)) of a JavaScript Interpreter/VM at runtime and I will consider it a 'good-enough' compromise sadface) -
Yes, using a preprocessor is a possibility.
But let's take a look at the idea behind: we are adding specific language extensions because the requested functionality is not supported, which are then translated by a seperate tool into native code.
If we now extend your example to the correct use of properties (which require the use of property() and setProperty(), as there is no such thing as a property in C++) or a more declarative way to describe a hierarchy of components using key-value assignment (as requested and suggested on the mailing list), basically everything on the list for an advanced GUI API (and everything that distincts QtQuick from the already existing, hardware-accelerated Graphics View API) we end up adding specific extensions and then, although having a native API, in creating and implementing our QtQuick components using those language extensions - a specific meta-programming language front-end - which is then translated into native back-end code by a seperate tool. What we implement in native code is the required supporting code, like constructors, destructors, operators, memory management and so forth.
If you bring this to a head, you'll end up exactly where we are right now. We have a specific meta-programming front-end language, QML, which is then translated by a seperate tool, the declarative engine, into a native representation (no, QML is not interpreted, it is translated into a native representation and no, V8 does not interpret JavaScript, beeing a just-in-time compiler it produces run-time optimized machine code, which is then executed). In both cases you will have to (learn and) use a specific front-end language (with different aesthetics) which is not C++.
You've already been told that a byte-code compiler for QML is possible, partially done and possibly integrated in Qt 5.1 if there is a strong momentum from the community.
-
Just food for thought....
Someone mentioned here the BlackBerry 10 Cascades framework based on Qt/QML as non toy app development, well, RIM seems to think that having a C++ alternative interface for Cascades as well (and not just QML only) is actually a good idea and looks like an implementation like that is very viable (as opposed as some people here seem to think), check this link for an example:
"BB10 developer documentation":https://developer.blackberry.com/cascades/documentation/getting_started/introtocascades.html
Also, a while ago I contributed to a declarative language and API that was very controversial as well called JavaFX with the very cool and infamous FX Script, well, if history has something to teach us, by version 2 they ended up adding a java interface for it because there were too many developers complaining that had to forcefully use FX Script instead of the language everyone knew. At the end, FX Script died, java interface prevaled, and even ended up adding an XML declarative interface (go figure) instead of FX Script.
-
Well, its basically a fluent interface wrapper around the proprietary Cascades elements and the Animation Framework for constructing objects, but there is no support for states, bindings or anything else we are used to know from QML (which doesn't mean having a fluent interface is not a viable idea).
-
@Lukas - you are aware in the manner surveys are done, aren't you? When probing about the public opinion, usually only like a thousand random people are being questioned and that gives an adequately accurate representation of what hundreds of millions are thinking.
This poll has kept a steady 2:1 ratio from the moment I first checked it with only 50 votes to now - over 150 votes. At this point I think it is safe to assume this is an accurate representation of what people think in general, and considering the claimed figure of about 500 000 Qt developers, about 333 333 of them would want to see efforts invested in a modern, customizable, hardware accelerated GUI API that is pure C++.
Or do you imply all the people who didn't find this thread or have no forum registration would vote against a C++ API? If so on what grounds? Because you think it is the right thing to do and value your opinion above that of hundreds and potentially hundreds of thousands people?
And furthermore, what do you imply about all the people who voted in favor of a C++ API? That they are clueless fools that don't know what's best for them?
With the risk of repeating what's already been said, if a new GUI API was conceived with the idea of being public and native above all to begin with, and extend QML functionality out of it - this issue wouldn't even be at hand. Alas, Nokia chose to offer the candy result of development efforts through their own language like so many other corporations before that, so at this point it becomes a burden to reshape the API in a native form, so may as well be better to create a new API focused at C++ nativity rather than modify the existing, QML/JS focused API.
As of the matter of stuff that is not technically possible with C++ - C++11 already provides solutions and I think it is about time Qt begins taking advantage of them, incorporating a compiler that is not ancient history and whatnot. BUT even without C++11 - Qt already heavily relies on code generation and the MOC and I cannot shake the feeling it would have been much easier to extend the MOC to generate some more boilerplate code from a nice and clean syntax that describes property binding in C++ source than reinventing the wheel and throwing in the mix a pile of new and avoidable tools in some ill conceived attempt to be "cool" and trendy in the philosophy of "monkey see, monkey do" and follow in the steps of other companies that work hard to make the excellent language that C++ is into the new assembler in both area of application and usage frequency, to push forward another "our way of doing things" like development is not fragmented enough already.
I get the feeling of C++ as well as Qt itself being neglected by Nokia, surely, no one argues they spent good (too good IMO) money on it, they made it LGPL which is a great thing, making adoption easier and usage of Qt higher, however the effort to morph Qt from a purely C++ application framework to a mostly QML application framework, extendable through C++, combined with the decision to NOT support the actual major mobile platforms and all the (potential) Qt supporting mobile platforms being pretty much dead, dying or stillborn - somehow it doesn't seem those decisions are in Qt's or its developer base best interests. And with all the yapping that despite being owned by Nokia, Qt is a community framework, where are the platform support and features this community obviously wants? And no, I don't think the community CAN or SHOULD even try to push against the bulk of the development effort that is in the hands of Nokia, it is Nokia that should direct that bulk of development effort to address the needs of is developer base, not protect its preposterous corporate interests that have already inflicted billions of dollars of damage and cost thousands of people their jobs.
And surely, C++ classes are still there, no one denies that, the problem at hand is not with old native stuff being gone, the problem is it is all DONE and there is NO new native stuff being developed, QML absorbs almost completely the development efforts, whereas other new promising technologies and platforms are being completely neglected and this has been going ever since the acquisition. Is this really "progress" or is Qt being sent on a wild goose chase, pimped to appear progress-like?
-
[quote author="utcenter" date="1338631185"]@Lukas - you are aware in the manner surveys are done, aren't you? When probing about the public opinion, usually only like a thousand random people are being questioned and that gives an adequately accurate representation of what hundreds of millions are thinking.[/quote]Yes, statistics uses samples to infer about a population, but this requires a certain sample size which is (for a common confidence level and interval) too low for the projected population size, which means that the result is not adequetly accurate. In addition, passively recruited or self-selective surveys are generally never representative, due to the erronous nature of sampling (and questioning in this case).
[quote author="utcenter" date="1338631185"]At this point I think it is safe to assume this is an accurate representation of what people think in general, and considering the claimed figure of about 500 000 Qt developers, about 333 333 of them would want to see efforts invested in a modern, customizable, hardware accelerated GUI API that is pure C++.[/quote]No, because this poll answers a different question (should there be an optional C++ API) than the one you've raised (should resources be spent on creating one). The latter question is answered in "this poll":http://qt-project.org/forums/viewthread/16693/, and for the vast majority of voters improving QML is more important than creating an optional C++ API.
[quote author="utcenter" date="1338631185"]Or do you imply all the people who didn't find this thread or have no forum registration would vote against a C++ API? If so on what grounds? Because you think it is the right thing to do and value your opinion above that of hundreds and potentially hundreds of thousands people? And furthermore, what do you imply about all the people who voted in favor of a C++ API? That they are clueless fools that don't know what's best for them?[/quote]No, that's your implication, not mine.
[quote author="utcenter" date="1338631185"]With the risk of repeating what's already been said ...[/quote]Yes, you are repeating what's already been said, discussed, disproved and clarified.
-
The sample size of the poll has varied and increased with the ratio remaining constant, that is an indication the poll results are accurate. Other than that, I can see bias and arrogance heavily influencing the direction of your arguments. I still didn't catch the reason for your claim probing more developers will dramatically sway the outcome in the opposite direction?
In that other poll, the "full C++ API", albeit not really a viable solution, still has plenty of votes, certainly more than "I am happy with QtQuick".
And in case you noticed, that other thread is about the direction of QtQuick, not the direction of Qt itself. And a modern C++ GUI API is the subject of the latter. It should be no surprise even to you it is not prevailing in a topic it is not the subject of.
Furthermore, in case you noticed, the title of this thread is not "Should QtQuck get a public C++ API?" but "Does Qt need a modern C++ GUI API?" and even thou this was somewhat addressed here, due to the design of the very foundations of QtQuick would be about as cumbersome as designing a new one.
bq. No, that’s your implication, not mine.
Indulge me of yours then, I am really curious about the motivation of your opinion being put over those of many people.
bq. Yes, you are repeating what’s already been said, discussed, disproved and clarified.
Repeated - sure, discussed - extensively, other than that you are now making things up. No one disproved the need of a modern C++ API for UI and I am sure those poll results are inconvenient enough for you to do your best to downplay them, but here is a news flash for you - other people have opinions too, and many of those are just as valid as yours, only more in count and with less bias.
-
I think we talk past each other.
The result of a vote is absolutely irrelevant for its representativity (and my personal well-beeing). We don't know what the vast majority of Qt developers think; we indisputably know what 158 people think (and that's what I've said). An extrapolation to the population is only valid if qualitative (a representative sample) and quantitative requirements (sufficient participation) are fulfilled. This has nothing to do with a personal opinion or downplaying, that's a statistical fact.
Even if the poll might sway to a different result it is still not representative, the same way the other poll is not representative for the population of Qt developers (but on the suppostition that a majority of people who have voted in this poll also have voted in the other poll - which is, of course, up to discussion - it is representative for the population of people that have voted in this poll).
I do not take part for or against, but I do correct people who try to affect the discussion in their favor with improper rationales. I do want to have Qt a prosper future, but this future has to be decided on comprehensible technical reflections, not sentiments or animosities. So I will correct people and ask for proof from both sides of the aisle. The impression, that I am the declarative envangelist, is pure and simple created from the fact that there is a disproportional high amount of subjectivity on the part of the native proponents.
Having a meritocratic consensus-based development model, which implies having discussions about the further development, is a good thing. Meta-discussions about objectively insufficient arguments aren't.
Every opinion is as valid as mine (and yours). But there are ones that prove themselves true and become facts, and there are ones that simply stay opinions.
In addition, I would like to encourage you to continue this discussion in a reasonable manner. If you think that I'm wrong just bring your own comprehensible reasoning and disprove; there is no need to constantly discredit and misrepresent me (or anyone else).
-
Why exactly isn't this poll representing the mind of Qt developers? It is found in a place that is supposed to be visited by Qt developers, so my bet is those current 158 votes come from Qt developers. If 50 random people think the same as 100 random people, who think the same as 150 random people, well, I'd say we have a very obvious, distinctive projection for what 200, 500, 1000, 5000 and so on people will be thinking. I don't think all the people whose vote will bring representativeness to this poll are hiding somewhere, and if I recall correctly, there was a suggestion to post the poll at the Qt project front page, which would have caused a significantly higher amount of participants, hopefully depriving you of your argument the current number is insufficient, although it retained a literally constant ratio as it grew.
As for the merits of meritocracy - just look at what it did to Nokia's overall business. I am not one of those people who consider the general population to be stupid enough to be told what it wants by the industry, and I bet Nokia would not suffer this tremendous blow if the direction of the company was not determined by those smart-a$$e$ which drove it into the ground, potentially the same management that does the direction picking for Qt after the acquisition. Ever considered that the decision makers have not become decision makers for being exceptionally good at decision making? Ever considered whether the priorities of those decision makers may not be in the interest of Qt? After all, they deliberately avoid making the ONE DECISION to make Qt a rousing success, and geez, I really "wonder" what is their motivation for it???
I hope you realize that acting as if you present facts and your opposition doesn't - that doesn't really materialize into reality, it is common tactic to appear as having the upper hand in the eyes of what you assume is incompetent public without really having it. There is only one noteworthy fact in the bulk of those 120 replies, and that is the result of that poll you are hasty to dismiss right away. A modern, native, cross-platform, hardware accelerated C++ GUI API is not what I or any other individual want, it is what the world needs, because there is no such animal in existence. On the other hand, declarative, interpreted, VM centered GUI APIs are already too many to count. It is only obvious that the focus of Qt should be on what doesn't exist and users demand, instead of arriving late to an area already crowded with more attractive, open and widespread solutions. Pioneering innovation should take precedence to giving your own twist on clichéd ideas you arrive late to.
On a side note, I really admire how you claim this poll means nothing and in the same time point to the other poll as having meaning, ironically, the other poll is lower in both participants and rating, which doesn't sit well with your argument on why this one is devoid of representativeness. And YOU talk about OBJECTIVITY - you are further from objective than obesity from sub-Saharan Africans :)
-
Every poll has flaws. But a poll is better than pure assumptions. A stated opinion has more value and influence than a silent opinion. With that in mind, I contest that this poll has no meaning. It does - it shows that of those active in the Qt forum, 2/3 of the developers want a C++ GUI API.
Assuming this forum represents the Qt developers quite well, this is the strongest voice of opinion that is out there. Give me a better one, or accept it and act upon it.
-
Again, we talk past each other.
I have never said that the extrapolation might not be correct or that it has no meaning, we just have no statistical evidence that it actually is or has for the population of all Qt developers. We indisputably know what the people who have voted think, but we do not know what the vast majority of people think.
It is not about the result (which is, again, irrelevant for its representativity), it is about the extrapolation - which might be true, or not. We can't answer this question with adequate accuracy. The representativeness (for the population of all Qt developers) suffers from the passively recruited or self-selective nature, the insufficient participation and the questioning.
The initial statement was that this poll shouldn't be used to extrapolate to the population of Qt developers ("... do not presume to know what the majority of people thinks ...") and I was told that this statement is statistically wrong. I don't think so, because for doing so we have to make assuptions we cannot proof due to the nature of this survey.
It is, again, not about the result and I do not question it. Although having a personal preference I'm satisfied with any result, and if you would have read the thread you would know that I have already stated that I think that Qt should have a native C++ API as well (but I also see the advantages of the solution we have now).
I have never "...claim[ed] this poll means nothing and in the same time point to the other poll as having meaning ...". Both have an insufficient meaning for the extrapolation, and both have a sufficient meaning if you change the statistical constraints, the sample ("... on the suppostition that a majority of people who have voted in this poll also have voted in the other poll ...") and the population ("... the population of people that have voted in this poll ...").
I do not comment on the situation of Nokia itself and the quality of the management (or the lack of), especially of Stephen Elop, because that's quite another matter. But decisions regarding Qt are up to the Qt team and are made on purely technical, not corporate-policy, details.
-
You did refer to that other poll as being demonstrative of Qt users being happy with QML. That implies you giving it weight over this one. If you regarded that other poll just as meaningless as this one, you shouldn't do this, but you favored it because it sits better with your own opinion you are pushing to establish as some kind of reference to being right.
If you wait on like 50% of the claimed number of 500 000 Qt developers to participate in order to give gravity to the poll - this may very well take forever, especially since there is no initiative to bring the poll to a more public place, and considering as comments cease it will become even more obscure as it sinks back in pages.
I don't know if you can tell, but you are beginning to sound more like one of those financists who twist spaghetti in order to present some barebone concept as something complex and incomprehensible.
And if what you say about the decision making behind the direction of Qt has nothing to do, what would explain the dramatic shift in direction that "coincided" with the acquisition? Do you imply QML would have become main focus of Qt and Android and iOS would be unsupported if Nokia never purchased Qt? I cannot help but wonder what is the non-corporate, purely technical reason to not support the most popular platforms at the moment?
And in the end, isn't all this hilarious, turns out we both want a native C++ API and appreciate the advantages of QML, so why this conflict :D
-
[quote author="Lukas Geyer" date="1339013069"]Again, we talk past each other.
It is not about the result (which is, again, irrelevant for its representativity), it is about the extrapolation - which might be true, or not. We can't answer this question with adequate accuracy. The representativeness (for the population of all Qt developers) suffers from the passively recruited or self-selective nature, the insufficient participation and the questioning.
[/quote]I do not think we talk past each other. I answered specifically to your statements.
My post was about the result. I stated that the extrapolation to the whole group of Qt developers is irrelevant, as this forum is the place where they congregate and voice their opinions. In a representative meritocracy, only those who decide to take part in a process gain influence. This forum is open to all Qt developers, it is publicly visible on the internet, and it has no competing other forum.
So to repeat myself repeat myself: the result is relevant, the extrapolation is not.
-
[quote author="miroslav" date="1339058649"]In a representative meritocracy, only those who decide to take part in a process gain influence.[/quote]
Meritocracy doesn't mean giving influence to those who hang out in some forum, it means giving influence to those who do the actual work (of improving Qt).
[quote author="miroslav" date="1339058649"]This forum is open to all Qt developers, it is publicly visible on the internet, and it has no competing other forum.[/quote]
Sure it has.
Most importantly, there's the "official mailing list":http://lists.qt-project.org/mailman/listinfo.Then there is...
- http://qt-forum.org
- http://www.qtcentre.org/forum/
- http://www.developer.nokia.com/Community/Discussion/forumdisplay.php?219-Qt
- ...
And in addition to that, various forums all over the net for other languages than English, like...
-
[quote author="jdavet" date="1339069428"][quote author="miroslav" date="1339058649"]In a representative meritocracy, only those who decide to take part in a process gain influence.[/quote]
Meritocracy doesn't mean giving influence to those who hang out in some forum, it means giving influence to those who do the actual work (of improving Qt).[/quote]
If Qt would only care about the opinions of those who work directly on it, why implement Open Governance? Your statement is simply not correct. Qt is a development toolkit. It's goal is to be used by developers (who do not necessarily need or want to work on Qt directly, but they are stakeholders).
[quote][quote author="miroslav" date="1339058649"]This forum is open to all Qt developers, it is publicly visible on the internet, and it has no competing other forum.[/quote]
Sure it has.
Most importantly, there's the "official mailing list":http://lists.qt-project.org/mailman/listinfo.Then there is...
- http://qt-forum.org
- http://www.qtcentre.org/forum/
- http://www.developer.nokia.com/Community/Discussion/forumdisplay.php?219-Qt
- ...
And in addition to that, various forums all over the net for other languages than English, like...
- http://qtfr.org
- http://www.qtforum.de
- ...[/quote]
Arguably, of all those have been superseded once the official Qt Forum moved in with the Qt Project. And a mailing list cannot do a poll. I maintain that this forum is the official one provided by the Qt Project. If a poll is done here, it should have way more weight than any other place, since the Qt Project is inviting all stake holders to this forum.
-
[quote author="jdavet" date="1339070141"][quote author="miroslav" date="1339069925"]If Qt would only care about the opinions of those who work directly on it, why implement Open Governance?[/quote]
So everyone (not just Nokia employees) has the chance to work directly on it... :-)[/quote]
And Mercedes-Benz builds cars for the fun of it, not for people driving them?
-
[quote author="miroslav" date="1339070589"]And Mercedes-Benz builds cars for the fun of it, not for people driving them?[/quote]
Apples and oranges:
Qt: meritocratic open-source project
Mercedes-Benz: shareholder-owned top-down-managed for-profit corporation.Also, no one said that those who work directly on Qt (and hence hold influence) all do so just "for the fun of it". They (or their respective employers) may have all kinds of motives, including trying to please Qt users.
But the meritocratic open-governance model simply does not, in any way, give any formal influence to those users directly.
If you want to get something changed in Qt, you either need to get involved yourself (with actual work, which will over time gain you respect and influence), or convince people who already are in this position of your opinion (which they are free to accept, refuse or ignore).There's no automatic entitlement to any influence just by "being a consumer" and "hanging out in the right forum" - its up to those who actually do the work, whether they let their own opinions be influenced by user opinions (like this poll), or not.