On Sep 28, 2011, at 2:28 AM, <[email protected]> <[email protected]> wrote:
> > 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 Will get better I'm sure. > > 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. Yep. > > >> - 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. Well I actually don't want to mix QWidget world into QML2, it's because shortcuts and window state restoring/saving that I use a QMainWindow. I could be fine throwing a top level QSGView because all my app is QML based. > > 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. Yes I could see some use case, as I maintained QGraphicsProxyWidget quite some time. In that particular use case I'm talking about I don't need it. > > 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. This I agree. > >> - 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. But I still think that shortcuts should work in a pure QWindow/QML2 world. Today QML doesn't provide shortcuts support (you can get key events but you need to have the activeFocus on the item which block a bit the shortcut concept) so I think it should be built in in one of them. The fact that I fallback to QMainWindow is because I have no other choice. Too bad that the mix can't work. I investigated on why it doesn't work. It's because events are directly propagated to the active QWindow, they don't go through QApplication::notify (which sits in widgets now) therefore the shortcut map is not used to check if any shortcuts could be triggered. One solution would be to move back the shortcuts map to QtGui and then check it before propagating to the active QWindow. I opened : https://bugreports.qt.nokia.com/browse/QTBUG-21734 > >> - 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. I found out and patched QtWebKit. https://bugs.webkit.org/show_bug.cgi?id=68934 QSGCanvas moved away from QGraphicsSceneEvent to other types of events (e.g. QMouseEvent). > >> - 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? Will do. > >> - 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 It has been fixed before I pushed my merge request. > > >> 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. Yep I reported it :D > > Thanks for the feedback, it is good to know that we are not running out of > work to do anytime soon :) :D, you're welcome. I wanted to make sure some issues where taken into consideration. > > 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
