Does Qt need a modern C++ GUI API?
-
... 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.
-
^^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.
-
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.
-
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.
-
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.
-
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:
bq. (C++Builder supports Win32 and Mac OS X applications, but does not support Win64 applications.)