On Sep 27, 2011, at 8:08 PM, ext Alexis Menard wrote: > > Today I made the jump and updated an app which 80% QML based. > We use almost nothing from QWidget (we use what we can't find in QML).
Hi Alexis, Sorry to hear your initial What we have done so far is to try (and I say try) to separate the widgets into their own module and keep it working as before. Then we have brought the QML 2 stack up on top of the new QWindow / lighthouse API. We have so far not spent any effort to merge these two worlds. What is supported right now is 100% QML 2 or 100% widgets/QML 1. The problems you describe below are expected when mixing the two worlds. > - First I have to use an horrible wrapper to put my QSGView as the > centralWidget of the QMainWindow. QML, neither QWindow support > shortcuts so I have to use that one. Also QWindow doesn't support > saving and restoring its geometry which make it impossible to use it > as a non mobile use case (where the QWindow is always fullscreen). We have talked about two classes to support mixing and neither of them are started. Embedding QML 2 into Widgets: Used to put QSGView classes into existing QWidget/QGraphicsView apps. The primary usecase is when doing a bit of QML inside a complete QWidgets based app like your usecase, typically when gradually porting your app from a QWidget based stack to QML 2. Embedding of QWidgets into QML 2. Similar to the QGraphicsProxyWidgets class. The primary usecase being when an application is written in QML wants to make use of an existing QWidget based component, like a text editor. I don't know who will implement these classes and when it will be done yet. It sounds like you already started on the first one :) We want to get the QML 2 stack good and stable first, and that is where we are currently working. > - All my shortcuts are not working anymore, I couldn't figure out why > yet. It kills a lot of use case for desktop but that's fine for mobile > as you don't have shortcuts right? No we don't... I hope shortcuts still work in a QWidget-only app in Qt 5. > - Focus handling seems really strange. For some reason the WebKit > WebView can't get clicks/keyboard focus and inputs (it may be a bug > there which I'm gonna fix if it's the case). As I said, we're not trying to mix the two worlds. QML has its own focus handling and if the QML window is active it thinks it has focus. When merging the two worlds, some supporting code in both QWindow and inside QSGCanvas is probably needed. > - QPA has some issues with KWin. For some reason the state reported is > wrong : maximizing/minimizing seems to be incorrectly reported to the > WM so the buttons of KWin are in a inconstistent state (if it doesn't > actually screw up the rendering of the window decoration). It's not > 100% reproducible but happens a lot. Could you make this into a bugreport? > - TextInput QML element doesn't work at all. The auto-tests were > commented to make the refactor branch built but this element doesn't > work. Setting a text on it (which is N#1 use case) doesn't trigger a > repaint. It was auto-tested btw. Yeah, I came across this one yesterday too. I believe this bug covers the same problem: https://bugreports.qt.nokia.com/browse/QTBUG-21697 > So it's in pretty good shape for your use case or the auto-tests but > they don't cover an extensive usage (unfortunately). I thought > sticking with QML would help me to avoid such issues but so far both > transitions (QML 1.1 to QML2) and this one were with pain (and it's a > simple app). I also still have feature loss from Qt4 like transulcent > top level QSGView. Yeah, there is https://bugreports.qt.nokia.com/browse/QTBUG-20768 for that. Thanks for the feedback, it is good to know that we are not running out of work to do anytime soon :) best regards, Gunnar > >>> >>>>> 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. >>> >>> I meant "whoever is making these changes". It doesn't matter which >>> company >>> they work for. If anyone wants to merge major changes, I want to see that >>> person or group provide a credible commitment to quality on the reference >>> platforms. >> >> Ok, I can agree to that :) >>> >>> I'm working on QUrl and I intend to provide that commitment when I ask >>> that my >>> code be merged. >>> >>>> 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. >>> >>> Those are the platforms I want: the reference platforms. Other platforms >>> will >>> depend on interested people showing up and doing some work. >>> >>>>> 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. >>> >>> That's the assurance I wanted to know: that it's not noticeably worse >>> than the >>> current code. Sure, problems will be found, that's not the issue. >>> >>>>> - 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. >>> >>> Understood. I'm not opposed to it. I just want to be clear here: this is >>> asking for an exception to the minimum requirements of merging code ("it >>> works"). >> >> Yes it is. However in this case I believe it's justified because it brings >> us much closer to Qt 5 by having the biggest architectural changes in >> place. Any time spent on doing development assuming the old architecture >> is at least partially time we're loosing. >> >> Cheers, >> Lars >> >> >>> >>>>> 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...). >>> >>> Right. >>> >>> But if we come to the point where we're almost ready to release, but we >>> haven't reached this state yet, it's grounds for delaying the release >>> further >>> if there are people still working on the code. Even if it's just one >>> person >>> doing part-time job. >>> >>> So if anyone has deadlines they need Qt 5.0, they should invest in making >>> Qt >>> 5.0 release-ready (by the community's definition of "release-ready"). >> >> _______________________________________________ >> Qt5-feedback mailing list >> [email protected] >> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback >> > > > > -- > Alexis Menard (darktears) > Software Engineer > INdT Recife Brazil > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
