On 9/5/11 2:03 PM, "ext Thiago Macieira" <[email protected]> wrote:
>On Monday, 5 de September de 2011 11:41:49 [email protected] wrote: >> We are getting closer to the point where we integrate the Qt refactor >> branch. What this branch does is that it separates most of Qt's desktop >[snip] > >Hi Gunnar > >That's great news! > >> These branches are not at feature parity with Qt 4.7 yet, and nor will >>they >> be for a quite some time. But we want to push the changes into the >>master >> codeline so that the structure we have mentioned in blogs and other >>forums >> gets visible in terms of code. > >What would be the consequences if this branch were not merged just yet? >I'm >especially concerned about the gap in the feature parity, especially on >basic >features: I don't really think the gap in features matters that much right now. We know that this change has to happen, and the earlier we do this the better. The reason is that it sets the direction for Qt 5 and gets everybody to work on the same stack. And with Lighthouse, we have the platform layer nicely separated. The Qt stack itself is in pretty good shape as the xcb and wayland backends show. It's the window system integration on Windows that requires work. So I don't think waiting longer will not help us in any way, but lead to split efforts on both branches, something that would in the end delay us on the way towards Qt 5. > >> Currently we have "official" support for single-window, QML 2 based on >> OpenGL on Linux/X11, Linux/XCB, Linux/Wayland and Mac OS X. There is >>some >> rudimentary support for the same setup on Windows, but it is still work >>in >> progress. Our stack works on top of Software Mesa (very slow), LLVMpipe >> (very fast) in addition to real OpenGL hardware (usually fastest). > >I'd say at least Windows support needs to be on a decent state before >merging >is allowed. I can't see what we could gain from waiting. Qt 5 is right now in heavy development, it's not something to use in production yet. The merge will help as more people will use the code base. > >I'd also like to see a commitment to reaching feature parity and platform >support in the new code by the 5.0 feature freeze. >From whom do you want that commitment? I assume you mean Nokia here. Nokia won't commit to supporting all platforms Qt 4 currently supports, and that has been communicated before. The main platforms for Qt 5 are Linux (X11 and Wayland), Mac and Win. But whether all of them will reach the same quality level with 5.0 depends not only on Nokia. > >> Standard widget based applications still works, but they are not our >>current >> priority. We will pick this up once the QML 2 stack is more complete. > >Does that mean that current applications, built with QWidgets and >Graphics >View, will continue working after this merge, provided they update their >includes and .pro file? Does anyone know what their state is right now, >before >the merge? Yes, they will. I've been testing this quite a bit with the xcb backend, and someone even had designer up and running. But this is a fair point, and we should do some final testing of this before we merge. > >I'd say that we need for merging that: > - refactor branch be at "feature parity" with current master Not sure what you mean by that. Refactor is in many ways better than current master, containing many fixes to the multithreaded rendering in QML that we don't have other places as well as a cleaned up architecture. And we will get some regressions no matter how long we wait. Waiting too long will simply lead to us finding them too late. >- new features work as intended on all reference platforms I tend to disagree. There's currently 1.3 million lines of code in qtbase/src. A lighthouse platform plugin is less than 15k LOC. This basically means that the window system integration is around 1% of the code base. There's also lots of work we need to do in other modules like QtMultimedia and other places that requires refactor. Keeping everybody else that works on other parts of Qt (in qtbase or on top of it) and needs the refactor branch waiting for one port is wasting a lot of peoples time. > >And by the feature freeze: > - master reaches "feature parity" with 4.8 on all reference platforms It's the right goal, but it might require also some people/companies outside of Nokia to step up (and yes I know that's still a bit difficult right now...). Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
