Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Does Qt need a modern C++ GUI API?



  • 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...

    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...

    And in addition to that, various forums all over the net for other languages than English, like...

    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="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 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.



  • [quote author="jdavet" date="1339072135"][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.[/quote]

    How is this relevant? This has nothing to do with whether or not the opinions of the poll in this forum represent the people involved in Qt well enough or not. And you misunderstand the nature of corporations obviously, but that is a different issue.

    [quote]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.
    [/quote]
    I think you are being mistaken. Qt users are developers, not the usual end-users. It is special for the Qt project that Qt developers and users have a close relationship, influence each other and listen to each other. It has been like that even before the Qt Project was started, when Qt was still fully controlled by a "shareholder-owned top-down-managed for-profit corporation".

    Final statement: I maintain my point that a poll here in this forum represents the Qt community quite well, and that the result is that 2/3 of the people who care to raise their opinion think they need a modern C++ GUI API in Qt.

    That is it. Recursing to constitutional arguments is a strategy to avoid arguing about the problem at hand, in this case the poll. Have fun, I am out.



  • [quote author="utcenter" date="1339017756"]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.[/quote]I didn't, quite contrary to. I said that according to the other poll "... for the vast majority of voters improving QML is more important than creating an optional C++ API ..." which does neither imply that they "... [are] happy with QML ..." (quite contrary to, as this option is also available and has not been voted) nor that the other poll has more weight ("... the other poll is not representative for the population of Qt developers ...").

    [quote author="utcenter" date="1339017756"]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.[/quote]I didn't, quite contrary to. The whole discussion is about you stating this poll as a reference for the population of Qt developers ("... it is safe to assume this is an accurate representation of what people think in general ...") and it "... being right ..." (a definition I didn't give) and me trying to explain you that both cannot be used as a reference from a statistical point of view, for any conclusion.

    [quote author="utcenter" date="1339017756"]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[/quote]I don't think we have to, quite contrary to. I said that we need "... qualitative (a representative sample) and quantitative requirements (sufficient participation) [...] fulfilled ..." which will be quite hard due to "... 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="1339017756"]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.[/quote]It is not about what we know about us, it is what we supposedly know about others, or not.



  • [quote author="miroslav" date="1339058649"]I do not think we talk past each other. [...] My post was about the result.[/quote]

    Yes, but mine wasn't, it was (just) about the extrapolation.

    "This poll fulfills the statistical requirements to extrapolate to the population with an adequate accuracy." - No, because we cannot proof the assumption, that those people who have voted are a representative sample of the population, with adequate accuracy. It is an assumption, which might be true, or not. We don't know, with adequate accuracy. This is a problem of the self-selective nature and the insufficient participation.

    It isn't about who is wrong or right, because we don't know, at least not with adequate accuracy. ;-)



  • bq. No, because we cannot proof the assumption, that those people who have voted are a representative sample of the population, with adequate accuracy

    You cannot prove they aren't as well, so please stop acting as if you are right. Details might be inconclusive at this point, but all that we have for sure is totally in your disfavor, so at least delay your crusade until balance shifts to give some substance to your claims.

    Today on the news I stumbled upon a poll that made a statement with political significance, based on 1000 interviewed individuals out of a 4 000 000 population. If 1000 out of 4 000 000 is accurate enough to put on the news by an agency that does this kind of stuff professionally, this poll actually has a higher percent of participation, if we assume there are 500 000 Qt developers out there, which is a generous estimate to begin with.

    So please, enough with weaseling out of the facts already!



  • ... sigh ...

    Again, this is not about the result, it is about the statistical value of this poll, which would be just as minor if the result would show a different picture. It might not only be inconclusive, it is inconclusive - that's the claim.

    Sample sizes are degressive (the larger the population, the smaller the proportional sample size), not linear. 1000 out of 4000000 are sufficient, 162 out of 500000 aren't. In addition, those 1000 are activly recruited, not passively. The poll you've cited differs qualitatively and quantitatively.

    But you are right, this poll isn't not representative, it is qualitatively not representative with a certain probability and quantitatively not representative - which, however, doesn't change the fact that it should not be used as a reference for the population.



  • It is a FACT that with this rate of participation this poll has a high margin of error, just as it is a FACT there is no better and more accurate representation of the needs of Qt developers. It is easy to be a naysayer, but isn't the constructive responsibility of criticism to offer improvement ideas? Without that, it is just trolling...

    What else should we use as a measure for the population? You use the best you got, as simple as that! You criticize and downplay the importance of the most representativity of this poll, but do you have something better?

    Mind sharing with me that function, according to which 0.00025% of 4 000 000 is representative and 0.00032% of 500 000 is not. I'd like to see how it grows...



  • [quote author="utcenter" date="1339141331"]Isn't the constructive responsibility of criticism to offer improvement ideas?[/quote]You are right, but why are we not just doing it then?

    Imagine we would have used the time we have spent convincing other people to do the work we are interested in using disputable arguments to extract the valuable information from this thread, like the binding concept using variadic templates and lambdas or the fluent interface using a builder pattern, to actually create an implementation sketch of the native interface.

    Imagine instead of advertising to vote and complain we use the attention to ask people to spend this time to contribute.

    Imagine a minuscle fraction of those supposedly hundreds of thousans of developers actually does this.

    Imagine we would already have a native interface because we stopped moaning and started doing.



  • People have been imagining for quite a while, singing songs about imagining, but imagination does not necessarily results in a manifestation in reality.

    Qt is a way too big, deep and overly complex project for community induced changes in direction. Additions - YES, fixes - YES, minor enhancements - YES, but not what you talk about. It is not about moaning, it is about giving the QT management an idea of what users want, because this requires a change in direction. It is like asking volunteers to push a train of its tracks, an object of massive weight, massive momentum, and a massive engine to move the whole thing. You don't change the direction of a train by pushing it, you change it by coordinating with management so the tracks are being laid in that direction.

    You present the issue as if we live in some magical, fairy tale world, but we live in a harsh reality that often renders us powerless to influence big changes. There IS such thing as impossible, we don't live in a world where you can achieve anything we put our minds to, there are many things that don't depend on us.

    I cannot sketch a Qt compatible implementation scenario - this can only be done by the people who have designed and know by heart, what I can is do make it from scratch, not using the already existing infrastructure as building blocks.



  • No, quite contrary to, there is always something to do for everyone.

    Creating a wiki page summarizing all the ideas which have been brought up so far for a native interface (as sparse as they are) serving as a place to go for interested people requires no intrinsic knowledge at all.

    Maintaining a forum thread where these ideas can be discussed and improved and encouraging people to contribute to it requires no intrinsic knowledge at all.

    Joining the mailing list or the chat, asking for and discussing those contributions with the developers requires no intrinsic knowledge at all.

    Actually gaining instrinsic knowledge for a specific part of Qt, creating a summary and good examples out of it and thus enabling other people to get familiar with it faster requires no instrinsic knowledge at all. If there are specific questions just join the mailing list or the chat, and you will usually get a valuable answer within a minute, directly from a Qt developer.

    Picking specific problems, liking bindings or interface design, providing and sharing general ideas, sketches and prototype implementations, which then can be later on integrated and improved in a Qt-ish way by people who actually have intrinsic knowledge requires no intrinsic knowledge at all. Just take a look at the binding concept using variadic templates and lambdas. It isn't even quite Qt-related, but it serves as possible solution for a problem a native interface for sure has to solve.

    Improving the existing implementation might not require instrinsic knowledge at all. Just take a look at the mentioned fluent interface. All it takes is the ability to read a header and to add a set of methods, without even knowing what the to be improved class actually does.

    Starting your own implementations, which then might be rewritten, but still act as a basis others can built upon requires no interinsic knowledge at all. Creating a custom Quick component is as simple as creating a custom Qt widget.

    Requesting a new project in Qt's "playground":http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt, which serves as assembling and staging area and a common repository for all those various ideas requires no intrinsic knowledge at all. A Qt playground module fully benefits from the Qt project infrastructure, like the bugtracker, the continous integration system, the build system, the early warning system and much more.

    Participating in discussions and providing constructive feedback here at the forums, the mailing list or the IRC channels requires no intrinsic knowledge at all.

    Beeing a native evangelist, who spreads the idea and kindly asks for contribution at various media requires no instrinsic knowledge at all. There are acutally quite a lot people having extensive instrinsic knowledge about Qt, but not beeing part of the Qt development team.

    Originating a crowdfunded project, where interested people, who do not want to or are not able to contribute time or effort can donate money (I would) to fund a kickstarting project requires no instrinsic knowledge at all. If everyone of those, who are supposedly intersted in a native interface, gives a single dollar there would be enough money to pay a set of fulltime developers or a company having intrinsic knowledge to kickstart the project.

    Finding your own ways how to support the native interface project requires no intrinsic knowledge at all. Beeing spirited and creative is one, beeing a nuisance is not.

    The Qt team has always mentioned that if there is a momentum from the community they will support and contribute to the efforts. You can be sure they stick to their words.

    Yes, a native interface is quite a piece of work. But a journey of a thousand miles begins with a single step. You can either moan for noone taking it or you just take it on your own.



  • First of all, stop with the "moaning" - we are users and we express feature and functionality request. Calling this "moaning" is yet another of your attempts of discrediting and downplaying, and not intending to insult you, but it is getting pathetic.

    And second - besides parroting a part of my last post, you completely ignored its body - if you claim this poll is not enough representative of developer needs, do you have something better?

    Everyone can parrot, in this regard, considering you said you'd like a native UI API as well, why do you exactly keep moaning and waiting on others like me to do it, fund it or whatever?

    Until you provide a better source of Qt developer base wishes, realize this poll is the best we all got, stop trying to downplay in those numerous direct and indirect ways of yours. Your "loyalty" is not the kind that's admirable.



  • I see you've made your decision.



  • ^^Thank you!!!

    bq. The C++Builder roadmap has been announced and now includes exciting plans for 64-bit, C++11, ARM, iOS and Android.

    'Nuff said. It was only obvious that ignoring developer base needs will have its consequences the moment there is an alternative.



  • @utcenter

    bq. Nuff said. It was only obvious that ignoring developer base needs will have its consequences the moment there is an alternative.

    LOL :O)

    I came from C++ Builder to Qt and I can tell you that Qt is so much better than C++ Builder. And the funny thing: their roadmap says ARM, iOS and Android - so they do the very same like Nokia did with Qt framework - they will add support for the mobile market. The only difference: Qt already supports mobile devices and Embarcadero only has a roadmap. Maybe if they implement their roadmap they will see that they require a declarative language for the mobile market - I would laugh me. And if you finished your switch to C++ builder Nokia suddenly releases a C++ API for Qt ;O)

    So I wish you a lot of fun with C++ builder - I worked several years with it and finally switched over to Qt framework. :O)



  • [quote author="Uwe Kindler" date="1339482347"]@utcenter

    bq. Nuff said. It was only obvious that ignoring developer base needs will have its consequences the moment there is an alternative.

    LOL :O)

    I came from C++ Builder to Qt and I can tell you that Qt is so much better than C++ Builder. And the funny thing: their roadmap says ARM, iOS and Android - so they do the very same like Nokia did with Qt framework - they will add support for the mobile market. The only difference: Qt already supports mobile devices and Embarcadero only has a roadmap. Maybe if they implement their roadmap they will see that they require a declarative language for the mobile market - I would laugh me. And if you finished your switch to C++ builder Nokia suddenly releases a C++ API for Qt ;O)

    So I wish you a lot of fun with C++ builder - I worked several years with it and finally switched over to Qt framework. :O)
    [/quote]

    Which mobile platforms does Qt support ? Probably you meant those two platforms killed by Nokia. And to be a successful, a mobile framework needn't be declarative. First of all I would like to see Nokia release a platform which support Qt. The funny thing now is that all these debates go on Nokia don't have a platform that support their framework.



  • @Jayakrishnan.M

    As far as I know (I'm not a mobile developer yet - but maybe in future) Qt supports:

    • Symbian (I know you call it dead - but it is a mobile platform and it is currently supported by Qt)
    • MeeGo Harmatten (the same like symbian)
    • QNX
    • Windows CE
    • iOS (community port)
    • Android (community port in alpha stage)
    • RIM Playbook OS (based on QNX)
    • Raspberry PI

    How many mobile platforms supports C++ Builder?

    bq. And to be a successful, a mobile framework needn’t be declarative

    Which declarative mobile frameworks do you know besides QML?



  • Symbian and Meego are platforms with no future. The Android port is not progressing at all for lack of resources and some technical issues. There is a commercial port for ios by somebody. I agree with you on the RIM port, that is official. Pi is not mobile phone platform. Again Windows CE is not a mobile phone platform. What I was talking about was official support on mobile platforms. I don't know anything about c++ builder and I was not defending it. The point is that officially Qt is not available on any major mobile platforms. WP is Nokia's future and no Qt on WP.



  • Yes, it is really sad that Qt is not supported on WP.

    But I think Symbian, iOS and RIM are major mobile platforms and the Android port is still progressing.



  • I'am not hopeful of the ios and Android ports. Would they ever attain production quality so that we reliably create quality apps ? That is my concern. Yet these are the most important mobile platforms now. BB has only around 7% market share. For ios, there is a commercial offering, though I'am not sure of its quality. Information is hard to come by. That is why I think, if c++ builder provides support for both ios and Android that alone will make it more valuable than Qt, for mobile development, though may be it is more difficult.



  • @Uwe - no professional developer will ever count on the community ports of Qt for Android and iOS, which are broken, incomplete and severely lacking in very important aspects. Nokia is unlikely to ever OFFICIALLY SUPPORT those platforms, and OFFICIAL SUPPORT is what professional developers want and paying consumers deserve.

    The Android port hasn't moved an inch the last few moths, I am not aware if there is any development on the iOS front, but last time I checked was even worse.

    Symbian is dead, Meego was stillborn, same appears to apply to Meltemi, Raspberry Pi is a small project for geeks and hardly a market opportunity, Windows CE is a goner, WP is not supported, RIM seems to be the only platform with some viability but it is in decline too. The mobile future of Qt is as bleak as its native GUI future...

    I agree the API of Embarcadero is not as clean as that of Qt, but if they commit to officially supporting iOS and Android, plus already supporting Windows and MacOS, the professional edition of C++ builder is only 700$ - much cheaper than a commercial Qt license and with much wider market. At least Embarcadero are committed to C++, and if they officially commit to officially supporting iOS and Adroid - I am sold.



  • @utcenter

    Yes -you are perfectly 100% right. C++ Builder is much better than Qt. You should really try it - and bug the people in the Embarcadero forums instead of the Qt users ;O). I also think seriously about changing back to C++ Builder because Nokia is so evil and forced me to use its unprofessional LGPL license, its outdated widgets libary and now they also started their evil QML conspiracy.

    Nokia is so stupid. Instead of trying to make money with their rattly Low-Cost-Phones they should spend some millions to port Qt to iOS and Android and offer OFFICIAL SUPPORT to boost their competitors ;O).



  • Oh no, you are wrong, Nokia is so smart, smart enough to drop from 70% to 5% share for their flagship mobile OS and completely run it into the ground, smart enough to lose billions, give the boot to thousands of hard working people and become cheap enough for MS to take over, and when MS settles in Nokia, then the future of Qt gets really bleak.

    Congrats on your infantile attempts of mockery, but you will really have to try harder for it to work. Or better off, don't try to insult me, if you have to say anything of value on the subject - feel free to, or GTFO ;) I don't recall claiming for C++ builder to be better, in fact, my powers of observation detect that I actually called it "not as clean as Qt" in the very last paragraph of my previous post. So why would you infer I said otherwise? In an attempt to build up your solid argument? All I said is if Embarcadero provide official iOS and Android support, I can live with it, as it will beat having to deal with two different frameworks with inconsistent APIs for desktop and mobile, as I am forced to do presently.


  • Moderators

    Ok -- everyone -- let's try to keep it civil in here. This is obviously an emotional issue for everyone involved and (like any good holy war) spirits tend to run a little high. But, nonetheless, let's all try to stick to coherent and productive discussion and keep the jabs and aggression (both passive and active) down to a minimum.

    If that can't be done, then there's no point in continuing this thread.



  • @utcenter

    bq. All I said is if Embarcadero provide official iOS and Android support, I can live with it, as it will beat having to deal with two different frameworks with inconsistent APIs for desktop and mobile, as I am forced to do presently.

    Here are some infos about C++ Builder:

    http://docwiki.embarcadero.com/RADStudio/en/FireMonkey_Application_Platform

    bq. Visual Component Library (VCL) is an object hierarchy of visual components that are supported on Windows only (in Win32 and Win64 applications).

    The VCL is the C++ "widget" library of C++ Builder - comparable to the Qt C++ libraries. This library is supported on Windows only.

    bq. You can create FireMonkey applications that target the Mac OS X, Win32, and Win64 platforms.
    ...
    You can freely use the RTL in a FireMonkey application, but you cannot directly use the VCL in a FireMonkey application module.

    So you don't have consistent APIs for Windows and Max OS. Linux is not supported in any way. Android and iOS support is not available yet - only announced. In my opinion C++ Builder does not provide real cross platform support if an important desktop platform like Linux is missing completely.

    And regarding development of Windows 64 Bit applications with C++ Builder - forget it:

    http://docwiki.embarcadero.com/RADStudio/XE2/en/64-bit_Cross-Platform_Application_Development_for_Windows

    bq. (C++Builder supports Win32 and Mac OS X applications, but does not support Win64 applications.)



  • As far as mobile c++ development is concerned, I think Mosync offers better cross platform capability. It has support for all platforms including WP. I haven't used it so I can't say anything about its quality.



  • Cross platform support including iOS and Android support is also provided by the C# Mono Project:

    http://www.mono-project.com

    I haven’t used it so I can’t say anything about its quality.



  • ^^ - C# Mono performance sucks BIG TIME, which is the last thing either a user or a developer needs on a mobile platform with weak CPU and low memory. Heck, even Java is faster than C# mono, albeit with an ever more horrendous memory bloat. And on Android, with C# mono you simply add yet another VM to run on that poor hardware, it is certainly inferior to use a Java frontend with a native C++ backend with the NDK.

    @Jayakrishnan.. - yep, I've been using Mosync, unfortunate it is not a complete solution either, it supports all major mobile platforms allright, but for some reason they decided to not support desktops.

    I am also looking at Juce, which fully supports Windows, Mac, Linux since kernel 2.6, iOS and there is even an android port being actively worked on. It is not very expensive too. It does seem as the most viable solution for me at this point.

    There are also a few lower level C frameworks that support Android and iOS, SDL for one, but it is strictly low level, no widgets, components or whatsoever, not even a complete painting solution, although OpenGL is supported and there are already a few OpenGL accelerated OpenVG implementations, which could be of use. It is still too much work for me right now.

    Sadly, the APIs of all those alternatives are inferior to Qt, which kind of makes me sad Nokia purchased Trolltech, for if not, today we could very well have had a still C++ centred, more flexible Qt with official support for those platforms.



  • bq. Sadly, the APIs of all those alternatives are inferior to Qt, which kind of makes me sad Nokia purchased Trolltech, for if not, today we could very well have had a still C++ centred, more flexible Qt with official support for those platforms.

    I'm not very sad that Nokia purchased Trolltech because I use the LGPL version of the Qt framework and this license is only available because Nokia made it available. That decision gave Qt a great boost and accelerated further Qt development.

    In my opinion Qt is and will remain a C++ centered framework and QML won't change that. I think, if QML desktop components are released and the first GUIs based completely or partly on QML will popup many concerns about QML will dissapear.



  • I don't think anyone will argue that LGPL licensing is a good thing, especially with commercial licensing being so ridiculously expensive... But the LGPL license through Nokia comes at a steep price - no hope of officially supporting the most popular and profitable mobile platforms. On the other hand, it is possible that Qt would have been opened to a LGPL license even without Nokia, whereas the lack of platform support can concretely be associated to Nokia.

    Also I don't think Qt is C++ centered any more. C++ is being shifted in the bowels, from a primary language of programming to a language of extending and writing custom QML components. I can see the merits of such an approach, but when chosen to be exclusively developed, I can also see many downsides, which arise due to the lack of an alternative native API, not a public one anyway.

    There are many areas where QML is a winning combination, may I say applicable to the majority of developers and application scenarios. There are however the scenarios where QML is no longer an advantage and becomes overhead, the only way to avoid is depriving yourself from all the features that are exclusive to QML.

    QML is similar to a LEGO constructor, you get a number of ready-to-use components with different shapes and purpose, elements you can easily and quickly achieve general results. QML is applicable for people relying on extensive reuse of a few either stock or custom components , but when you change the components from few to many and reuse from extensive to none, the outcome of the equation changes. In my more custom line of work, like that of many others, the number of components is very high and the amount of their reuse is very low, to the point interfacing the component to QML becomes an extra and wasted effort, designing and connecting an application on QML and native level is a wasted effort too. This just adds another layer of considerations and work that has no actual purpose. At this point using QML is no longer about the ease and speed it normally brings, but a tedious task just to get the new nice features which aren't being incorporated into the old, "DONE" native API. And all this doesn't really stack with the resource overheads of QML too, as minimal as they might be on desktop machines.

    I for one don't think the issue of so many people with QML is a product of finding QML hard, fearing change or whatnot. QML is simple and in many scenarios - perfectly applicable with great results. But then again, there are the "deeper", more "out of the box" scenarios where you are faced with the following choice:
    a) - deal with QML interfacing even thou you don'y really need to, spend extra efforts so you can use all the new ready-to-use features
    b) - keep to the old API, avoid the extra work to interface components to QML but spend extra efforts to replace the beneficial aspects of Qt Quick

    So, while an undisputed improvement for many, there are those, to whom QML adds extra efforts, whether they chose to use it or avoid it or use it. And surely, you are free to pretend like QML never existed and in this regard neither did all the benefits of Qt Quick and do everything yourself, but THE POINT of using a framework is not having to keep reinventing the wheel but take advantage of that huge team of developers who got paid good money to add features to it.

    That is the reason I think so MANY people are in favor of a new native API - because for as long as QtQuick's nice features are exclusive to QML, users are put in a situation, where using Qt becomes less than optimal, either by having to incorporate QML's limitation in your design and interface your components to it, or by having to re-implement QtQuick features you lose if you chose to avoid QML. It is discriminatory to the needs of many developers, benefiting some while hindering others. And as it turns out, despite such scenarios being fairly rare, and most developers are after more trivial apps, where QML is an undisputed advantage, this poll indicates 2/3 of the Qt developers visiting this forum want an alternative. This is not surprising at all, since we are talking about C++, which is a complex and performance oriented language, after all, if a developer is after lush eye-candy, C++ is probably the worst choice, developers vote C++ when they are interested in deeper, more complex, more advanced and out of the box scenarios, in which the merits of QML aren't that pronounced but questionable and often - an obvious downsite. Qt made it easy to achieve results with C++, and it is just wrong for all those benefits to be redirected away from C++, the language that made Qt, both literally and figuratively speaking.



  • I think there are a lot of fears and "maybes" and "negative expectations" around QML that hopefully will vanish when QML matures and also the sceptical developers realize, that it is a good and easy solution that partners with QWidget very well.

    I thinks it is no surprise that a lot of people have fears because of this completely new thing. This always happens when something new comes out - even when the first train hit the rails many people had the strangest fears. They will dissapear if QML meatures and if there will be books and best practices that will answer the open questions.

    So I'm quite optimistic that also you will change your mind - maybe sooner, maybe later :O)



  • You seem to have troubles understanding English, I am not quite sure what gave you away thou, is it your wait on QML to "meature" or is it the fact you completely failed to address anything of my long previous post, and instead just repeated what you said your very last post.

    There is no problem with QML being new, complex or anything like that, on the contrary, it is nothing hard, nothing complex, it is just not applicable in many scenarios, and what is worse, it is not applicable when it comes to programming complex, productivity related software with vast functionality.

    It is not an issue of maturity either, no matter how mature QML will get, it will not get any more applicable where it is simply not designed to be applicable, high productivity, custom, specialized software is simply NOT an issue addressed in its fundamental design. Just like maturity will never make PHP as fast as native code and applicable for writing operating systems in PHP, QML will never be applicable to writing big, complex, productivity oriented applications. QML is perfect for the applications it is being showcased with - media hubs, frontend to web services, trivial applications with limited functionality and whatnot, in other areas it becomes a burden to use for the sake of getting the benefits that are exclusive to QtQuick, not included in the design of the old GUI API and hard to implement. You end up either bothering with using QML or bothering with implementing the things you lose by staying away from QtQuick.

    And just you still fail to understand this, let me put you in a way language will not be a barrier for you:

    !http://i48.tinypic.com/35jf9es.png(qmlsucks)!

    In general, the idea of QML is to improve on GUI implementations. In trivial apps there is little business logic and GUI represents a big part of the total code. With QtGui you can very well end up with more GUI code than logic code in the case of trivial applications, and QML addresses that issue perfectly, cutting on a significant portion of the code.

    BUT then again, there are the kind of applications where GUI is a miniscule part of the total application, a negligible amount compared to the logic. There is a high number of custom UI elements that need to interact with the core logic, but the overall GUI portion of the code is tiny, elements are responsible for their custom drawing. In this case QML helps you save on that INSIGNIFICANT GUI part but adds significant overhead having to interface the SIGNIFICANT component logic to it, so the little benefit if QML is totally displaced MANY TIMES OVER.

    And again, to avoid language barriers, here is an easy to get visual representation of this concept:

    !http://i47.tinypic.com/jpvw2d.png(youlose)!

    Hopefully now you, as well as others who have problem understanding finally get it :)

    The one big point you seem to keep on missing is that logic cannot always be isolated from the GUI, and in many creativity/productivity oriented applications you need to have it exposed to the user interface, and it is at this point where interfacing it all to QML becomes more prominent than the saving on GUI construction and QML miserably fails and becomes a burden you have to conform to for the sake of the technical benefits of QtQuick, which are absent from and hard to implement with QtGui. Or alternatively, you ignore QML and act as if no one moved a finger at Qt to make it better the last 3 years, both cases suck!

    And even thou serious software is a minority compared to trivial software, it is still FAR MORE IMPORTANT, as it is far more productive to both its developers and to its users. In this regard Qt is simply turning its back on developers of professional software, which perfectly explains the voicing of concerns from such people here in the forum as well as in blog and lab comments.


Log in to reply