I have been reading the discussions about Qt’s future and strongly feel that it's full of promise. Last year I used a different application framework but the company went bankrupt without notifying its users. I then tried several other frameworks but wasn’t happy with any of them. Then I came across Cosos2d-x and Qt and briefly tried both. I quickly came to the conclusion that QML (with JavaScript) was an extremely powerful way to develop systems and that I was able to use C++ if I needed to access existing libraries or required critical performance. IMHO, this one-two punch in some ways sets Qt above the fray and enable developers to create and deploy a wide range of applications, including complex and highy performant ones. QML can be used when it is appropriate and C++ can be used when it is appropriate.
When I last counted the QML types and C++ classes I found that the C++ classed outnumbered the QML typed by approximately 3:1. I’m certainly not suggesting that the ratio be close to 1:1 but there is some room here for improvement. I like that many of the new features of Qt 5.3 and some of its immediate predecessors allow users to access functionality in C++ or QML and hope that this trend continues. There are certainly several aspects of Qt that can be improved, like the Qt Creator editor for one, but Qt is an open source project and everyone has an opportunity to contribute by comments, suggestions or even code. BTW, I agree with the statement "I do not really care about .ui file support." I would, however, like to see some improvement in the Qt Creator design functionality, especially since the older Qt Designer appears to have more capability than the newer Qt Quick Designer. However, I personally disagree that "100% C++ GUI is fine." QML provides a MUCH better vehicle for GUI than C++ and after using C++ and Java for many years I can see tremendous benefit in QML. If someone wants to spend the time and effort to create GUIs in C++, then I wish him or her luck. I've experienced some pain with this in the past and I don't want to do it again. It's just my preference and may not be right for everyone. To Qt's bright future, Steve -----Original Message----- From: m...@rpzdesign.com Sent: Monday, April 21, 2014 12:55 PM To: Thiago Macieira ; development@qt-project.org Subject: Re: [Development] Question about Qt's future Thiago: I really appreciate your and Intel's participation in the open source Qt project. I think you misunderstood what I was talking about and forcefully rejected that which I did not ask. I want the "pattern" brought forward, but we should not try to bring the code forward. Let sleeping dogs lie. After reading these: http://qt-project.org/doc/qt-5/topics-graphics.html http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering What I think would be a solution is to create a starting point where Qt Widget 2.0 development could begin anew again based on the QQuickPaintedItem class. I think the notion of a Window with child custom controls is not too far fetched. My suggestion is basically to provide an early off ramp for QQuickWindow to allow for 100% C++ projects. This may even serve as the foundation for custom controls in QML as well, don't know enough right now to be dangerous. It would definitely provide current Qt Widget users a sense of ease that the Widget option is still available even though QtQuickWindow is the future focus. QML and QTWidget would then both use the same dual GUI/render thread foundation, but it would be good to have an early C++ jumping off point for QQuickWindow based projects. I do not really care about .ui file support. For all I can see, 100% C++ GUI is fine. What do you think? Cheers, md On 4/21/2014 12:19 PM, Thiago Macieira wrote: > Em seg 21 abr 2014, às 10:59:43, m...@rpzdesign.com escreveu: >> Can Qt Widgets design pattern be brought forward using the same OpenGL >> foundation >> that QML uses to instantiate controls? > > Short answer: no. > > Long answer: if you want it working in other platforms, without glitches > and > regressions, the effort required for this is enormous. It basically > requires > rewriting all or almost all widgets from scratch so that they work in a > retained-mode OpenGL scene graph, instead of imperative-mode raster buffer > painting. It's a complete paradigm change. > > Since this requires a rewrite, instead of doing it in QtWidgets and > risking > regressions that users will not accept, the idea was instead to do it in a > different module, one where we can experiment and at the same time clean > up > some of the mistakes that exist in QtWidgets and can't be cleaned up > without > annoying someone. > > That's the Qt Quick Components. > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development