Hi,
On Tue, Sep 6, 2011 at 5:35 AM, <[email protected]> wrote:
> On 9/6/11 1:14 AM, "ext Thiago Macieira" <[email protected]> wrote:
>
>>On Monday, 5 de September de 2011 21:32:15 [email protected] wrote:
>>> 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.
>>
>>Those are good reasons.
>>
>>> 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.
>>
>>Are there people working on QtGui in the master branch? If so, that's the
>>most
>>important argument for me. I see 82 commits there since July 1st, which
>>is the
>>same number as QtCore.
>
> All merges from 4.8 go into master (and need testing there), plus we are
> doing additional work in merging master to refactor in regular intervals.
>>
>>> >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 see that stabilisation would be gained. The more we allow of unstable
>>code
>>in Qt 5, the harder it will be to get it to releasable state. Just
>>remember
>>the state of the p4 main branches during 4.4 and 4.5 times, before the CI
>>gate.
>
> Yes, stabilization is needed. But the refactor branch is in a relatively
> good shape on xcb showing that the platform independent code is ok.
I disagree a bit with that.
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).
Our code only use one QMainWindow (for the shortcuts, and geometry
saving/restoring) and a QDialog(for modal popups out of the QML
scene). The rest (except some C++ backends to deal with SQL databases)
is entirely based in QML. We also use the QtWebKit module.
I thought updating would be straightforward as we have a very little
dependency on old QWidgets. Fixing the build was easy but having the
app working as before is not really straightforward.
- 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).
- 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?
- 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).
- 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.
- 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.
That's so far what I found after a quick test. When my shortcuts will
work again I can do a more extensive testing. And yes I'll try to be a
good citizen and submit patches (which I do usually).
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.
Otherwise overall I'm happy with the move at it was needed, I'm just
sad that QWindow doesn't support more desktop features like shortcuts
and geometry restoring/saving.
>>
>>> >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
