C++ cannot describe UI in a declarative, structured way, nobody claims that, with C++ the developer must structure the design himself, BUT it is not that hard AT ALL, and it allows you to skip two extra languages, glue code between them and C++, and the CPU cycles and memory needed for interpreting and running a VM.
bq. #1 C++ will always be a core language for Qt (I love C++ and can’t imagine it being anyother way)
#2 Most of the time QML actually improves your software architecture by drawing more solid lines between the front-end and the back-end.
#3 It’s not like C++ support has been dropped or anything.
1 - the problem is that "core" turns out to be low level logic. Let me give you an example - with QtGui everything you can do in the designer or with XML you can always do in C++, with QtQuick you no longer have that option, and unlike using the designer or XML, QML comes with a solid dose of various overheads
2 - I guess what you actually wanted to say is something like "draws more solid lines between GUI structure and application logic" - but not more so than for example HTML5, where you separate an application even further, you have structure, styling and logic, which is even more flexible. I hope you do realize the more a frontend is separated from its backend, the more overhead is induced? There is nothing faster and more efficient than using a C++ backend through its native C++ frontend. Even language bindings induce some overhead, not to mention the QML approach.
3 - C++ support on the low level has not been dropped, but C++ support for developing GUI applications is pretty much done, there is absolutely no indication Qt will dedicate any significant efforts into improving the outdated QtGui or change it for a better native GUI API
@capisce - what would be the point of stating the obvious, I am quite sure you as well as others know the cost of running a VM and interpreting code, as well as being isolated from C++ and only be able to access it through gluing and exporting stuff explicitly. I never claimed the performance overhead of using QML is dramatic, just that IT IS THERE and there should be an option to avoid it. I am sure there must be some kind of moral gratification from people using what you designed and working in the way you intended them to work, but the wheel has already been invented, and inventing other shape wheels may not always be the best idea, sure it may work for some, but I for one would like the option to keep it native, and it looks like I am not alone in this.
bq. If anyone believes that with C++ you can write modern GUI, so be it.
C++ may not be designed from the ground up to write modern GUI, heck it is a GENERAL PURPOSE LANGUAGE, so while it is not THE BEST tool to write GUI, it COMPLETELY SUFFICES to express any type of structure, be that of a UI or anything else. What people seem to fail to realize is QML is not code that gets executed, it is data that gets parsed by an interpreter which builds the structure entirely in the C++ way, the way I and many others want to be able to use Qt Quick.
If you think C++ is the wrong tool for you to write GUI, then by all means, DO NOT USE IT, but C++ IS THE RIGHT TOOL if you want to keep your application compiled to native binary, including the GUI, that is totally doable in C++. To you it may seem it is a tremendous difference between QML and C++, but whether you will inline an element into the body of another element to parent it in QML or whether you will create the element and pass a reference to another object in the constructor to parent it - it is not all that different, two different ways for doing exactly the same.
As I said in another thread, for people that are not used to C++ structure QML is easy since it allows you to describe the structure in code and have the interpreter build it for you. But many developers don't really need that tool to build structure. You DON'T DO PROGRAMMING IN QML, just because it is tailored to look like JS it is not a programming language, stating you program in QML is just like stating you program in XML, in both QML and XML you write data structure which some program will then read and do something with it.
So in the end it boils down to this - some of us appear to want the option of doing GUI programming rather than GUI describing. For describing GUI we already have tools that go beyond QML and are enjoying amazing worldwide adoption. It would have actually been better if Qt chose a HTML+CSS like approach instead of QML which mimics a programming language syntax but is a data structure language, which is a little backwards, and as I already said, HTML+CSS offers even more flexibility since you can separate structure from design. I honestly don't see enough benefits in QML to chose it instead of HTML5 for rudimentary app development. It has the benefit of being extendible through C++ but HTML+CSS+JS has many other benefits QML simply cannot offer like for example running on Android and iOS which totally dominate the booming mobile market, while with Qt the "running everywhere" is currently just an empty slogan that has little to do with the reality of the market.
Come on now, we don't even ask of Qt to be perfect, only to not be worse than MS and Apple, who do offer the option of keeping it native. Since when is it too much asking to be a tiny bit better than the world's greediest, monopolistic enforcers of proprietary technologies?