> Unfortunately that means there are now 4 completely separate UI stacks > to maintain in Qt - widgets, > QGraphicsView, the web and QtQuick v2. I wonder if they could be > harmonized at all? > > We can use QML to describe UIs in all four.
True - but I'm thinking more about the implementation. If someone adds a new feature to a QtWidgets control for example, how much extra work is it usually to implement that for QtQuick controls as well? On 21 April 2014 20:49, Steve Gold <steveg2...@gmail.com> wrote: > 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
