Discussion:
Merging refactor branches into master
g***@nokia.com
2011-09-05 09:41:49 UTC
Permalink
Hi,

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 widgets along with a number of currently less actively developed modules into their own libraries, in accordance with the module maturity list we published earlier this year and in line with Lars' blog about the intent of Qt 5. The over all goal is to simplify our graphics stack, minimize our platform/device dependent layer (lighthouse integration) and make sure QML and OpenGL are prime citizens in Qt 5.

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.

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).

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.

We're expecting to merge into master in 1-2 weeks time.

What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to <QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this for you. Run it in the root directory and you are done.
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx which integrates tightly with lighthouse. To keep changes to existing code minimal, we decided to keep the existing libQtOpenGL classes pretty much as is without any changes, and rather introduce new classes in QtGui for the classes we wanted.
- Printing support has been moved into its own library, libQtPrintSupport. We have a long term plan of creating a better printing API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we have spent some effort in removing the dependency on the current API's from the "Qt essentials". The API is unchanged.


Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack simpler to maintain and to have smaller footprint.


What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue and QJSEngine classes in libQtDeclarative)
- In new projects, see if you can use OpenGL functionality in QtGui instead of libQtOpenGL.so


What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes and add widgets/script/qtquick1 to your .pro files


What does this means long term?
- None of the existing libraries

I hope this transition will be as painless as possible for everyone. If you have further questions, don't hesitate to ask

-
Gunnar
Thiago Macieira
2011-09-05 12:03:32 UTC
Permalink
Post by g***@nokia.com
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!
Post by g***@nokia.com
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
Post by g***@nokia.com
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'd also like to see a commitment to reaching feature parity and platform
support in the new code by the 5.0 feature freeze.
Post by g***@nokia.com
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?

I'd say that we need for merging that:
- refactor branch be at "feature parity" with current master
- new features work as intended on all reference platforms

And by the feature freeze:
- master reaches "feature parity" with 4.8 on all reference platforms
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
l***@nokia.com
2011-09-05 19:32:15 UTC
Permalink
Post by Thiago Macieira
Post by g***@nokia.com
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!
Post by g***@nokia.com
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
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.
Post by Thiago Macieira
Post by g***@nokia.com
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.
Post by Thiago Macieira
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.
Post by Thiago Macieira
Post by g***@nokia.com
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.
Post by Thiago Macieira
- 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.
Post by Thiago Macieira
- 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.
Post by Thiago Macieira
- 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
Thiago Macieira
2011-09-05 23:14:35 UTC
Permalink
Post by l***@nokia.com
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.
Post by l***@nokia.com
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.
Post by l***@nokia.com
Post by Thiago Macieira
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.
Post by l***@nokia.com
Post by Thiago Macieira
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.

I'm working on QUrl and I intend to provide that commitment when I ask that my
code be merged.
Post by l***@nokia.com
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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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").
Post by l***@nokia.com
Post by Thiago Macieira
- 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").
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Samuel Rødal
2011-09-06 08:10:15 UTC
Permalink
Post by Thiago Macieira
Post by l***@nokia.com
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.
Post by l***@nokia.com
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.
Post by l***@nokia.com
Post by Thiago Macieira
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.
I guess the question is what you're comparing to. The plan is to remove
all non-lighthouse backends by Qt 5, and in that regard the refactor
branch is mostly on par or better than the master branch (the master
branch doesn't even have the windows plugin).

However, if you compare the windows plugin in the refactor branch to the
non-lighthouse windows backend in the master branch the latter is
definitely more stable at the moment.

--
Samuel
Thiago Macieira
2011-09-06 09:12:04 UTC
Permalink
Post by Samuel Rødal
I guess the question is what you're comparing to. The plan is to remove
all non-lighthouse backends by Qt 5, and in that regard the refactor
branch is mostly on par or better than the master branch (the master
branch doesn't even have the windows plugin).
However, if you compare the windows plugin in the refactor branch to the
non-lighthouse windows backend in the master branch the latter is
definitely more stable at the moment.
Right, that's what I am comparing to.

Suppose I produce a very, very fast QUrl implementation using Intel
intrinsics, but no ARM code, then I say "please merge this as KDE developers
need to get started porting", it wouldn't be accepted, would it? My employer
might be happy though...

And here's where I'm getting at: I'd like to make absolutely sure that Qt 5.0
runs on the desktops, not that it's a second thought, bolted on. I've heard,
in public and private discussions, comments going from desktops are not being
focus to outright discarding of desktop support for Qt 5, keeping Qt Creator
on Qt 4.

So yes, I am going out in defence of the desktops, creating opposition as in
"you don't get dessert until you eat dinner".

I want to apply the rules we've all had for years, like the "Rule of 3
implementations", the quality acceptance, or simply "it works as intended".

And to be clear: I'm not opposed to the merging, provided we all understand
it's an exception and we get some form of commitment from the people working
on this that they will work on what's left RealSoonNow™.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
l***@nokia.com
2011-09-06 08:35:17 UTC
Permalink
Post by Thiago Macieira
Post by l***@nokia.com
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.
Post by l***@nokia.com
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.
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
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.
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
I'd also like to see a commitment to reaching feature parity and
platform
Post by Thiago Macieira
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 :)
Post by Thiago Macieira
I'm working on QUrl and I intend to provide that commitment when I ask that my
code be merged.
Post by l***@nokia.com
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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
- 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").
Alexis Menard
2011-09-27 18:08:15 UTC
Permalink
Hi,
Post by l***@nokia.com
Post by Thiago Macieira
Post by l***@nokia.com
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.
Post by l***@nokia.com
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.
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
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.
Post by l***@nokia.com
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
I'd also like to see a commitment to reaching feature parity and
platform
Post by Thiago Macieira
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 :)
Post by Thiago Macieira
I'm working on QUrl and I intend to provide that commitment when I ask that my
code be merged.
Post by l***@nokia.com
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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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.
Post by l***@nokia.com
Post by Thiago Macieira
- 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
Post by Thiago Macieira
Post by l***@nokia.com
Post by Thiago Macieira
- 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
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
g***@nokia.com
2011-09-28 05:28:53 UTC
Permalink
Post by Alexis Menard
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.
Post by Alexis Menard
- 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.
Post by Alexis Menard
- 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.
Post by Alexis Menard
- 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.
Post by Alexis Menard
- 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?
Post by Alexis Menard
- 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
Post by Alexis Menard
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
Post by Alexis Menard
Post by l***@nokia.com
Post by Thiago Macieira
Post by g***@nokia.com
Post by Thiago Macieira
I'd also like to see a commitment to reaching feature parity and
platform
Post by Thiago Macieira
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 :)
Post by Thiago Macieira
I'm working on QUrl and I intend to provide that commitment when I ask that my
code be merged.
Post by g***@nokia.com
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.
Post by g***@nokia.com
Post by Thiago Macieira
- 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.
Post by g***@nokia.com
Post by Thiago Macieira
- 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
Post by Thiago Macieira
Post by g***@nokia.com
Post by Thiago Macieira
- 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
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Uwe Rathmann
2011-09-28 07:12:36 UTC
Permalink
Post by g***@nokia.com
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.
As author/maintainer of a 3rd party widget library ( Qwt ) I'm wondering
how my project can survive in the situation of having 2 different worlds.

For technical plot types like spectrograms, scatter plots etc I can't
imagine that something like QML could be the weapon of choice ( maybe I'm
wrong ). But for configuring attributes like scales, fonts, palettes or
less data intensive business charts ( bar plots, financial charts ) QML
should be a an option.

Hope it's obvious why I'm not excited about the idea of implementing the
same library twice - but what could be the concept for supporting both
worlds ?

I can imagine to introduce a layer where I can hide if my rendering code
( = translating plot items into graphic primitives ) is supposed to run
with QPainter or any other API - as long as it is available from C++ -
and I could try to write some code on top of the plot classes that does
what needs to be done to make it available for QWidget/C++ or QML.

Did you ever discuss the situation of 3rd party widgets and do you have
an advice ?

Uwe
j***@nokia.com
2011-09-28 07:44:17 UTC
Permalink
I would not be too concerned as we will make it possible to embed Qt Quick inside normal QWidgets,
as is already fairly easy to do with Qt Quick 1. Note that we are going to ship Qt5 with an HTML5 Canvas like painting API.
I did the initial port to QtQuick last year so you can already try it out on Qt 4.7 here:
http://qt.gitorious.org/qt-labs/qmlcanvas

This should be ideal for graph plotting within Qt Quick as is already demonstrated by the examples.
I would suggest that you implement the plotting charts in Qt Quick itself and simply embed your Qt Quick elements in a Wrapper Widget.
This should not add much extra effort apart from forwarding the API.

Regards,
Jens Bache-Wiig


As author/maintainer of a 3rd party widget library ( Qwt ) I'm wondering
how my project can survive in the situation of having 2 different worlds.

For technical plot types like spectrograms, scatter plots etc I can't
imagine that something like QML could be the weapon of choice ( maybe I'm
wrong ). But for configuring attributes like scales, fonts, palettes or
less data intensive business charts ( bar plots, financial charts ) QML
should be a an option.

Hope it's obvious why I'm not excited about the idea of implementing the
same library twice - but what could be the concept for supporting both
worlds ?

I can imagine to introduce a layer where I can hide if my rendering code
( = translating plot items into graphic primitives ) is supposed to run
with QPainter or any other API - as long as it is available from C++ -
and I could try to write some code on top of the plot classes that does
what needs to be done to make it available for QWidget/C++ or QML.

Did you ever discuss the situation of 3rd party widgets and do you have
an advice ?

Uwe
Uwe Rathmann
2011-09-28 09:15:55 UTC
Permalink
Post by j***@nokia.com
I would not be too concerned as we will make it possible to embed Qt
Quick inside normal QWidgets, as is already fairly easy to do with Qt
Quick 1.
I'm worried about curves consisting of millions of points. They need to
be mapped to target coordinates and painted afterwords each time the plot
needs to be refreshed. Is it possible to pass these points via an HTML
based API with an acceptable performance ?

And what about oscilloscopes ( a common use case of QwtPlot ), that can
only be implemented in an acceptable performance today with painting
incrementally ( painting new points on top instead of repainting
everything from scratch ) ?
Post by j***@nokia.com
This should be ideal for graph plotting within Qt Quick as is
already demonstrated by the examples.
I checked a Qt 4.8 snapshot, but was not able to identify what example it
is ?

Uwe
Samuel Rødal
2011-09-28 09:28:02 UTC
Permalink
Post by Uwe Rathmann
Post by j***@nokia.com
I would not be too concerned as we will make it possible to embed Qt
Quick inside normal QWidgets, as is already fairly easy to do with Qt
Quick 1.
I'm worried about curves consisting of millions of points. They need to
be mapped to target coordinates and painted afterwords each time the plot
needs to be refreshed. Is it possible to pass these points via an HTML
based API with an acceptable performance ?
And what about oscilloscopes ( a common use case of QwtPlot ), that can
only be implemented in an acceptable performance today with painting
incrementally ( painting new points on top instead of repainting
everything from scratch ) ?
Post by j***@nokia.com
This should be ideal for graph plotting within Qt Quick as is
already demonstrated by the examples.
I checked a Qt 4.8 snapshot, but was not able to identify what example it
is ?
Uwe
You can always use a QSGItem representing a QImage that you dynamically
update and upload to a texture for cases where you want to do QPainter
or custom rendering.

--
Samuel
j***@nokia.com
2011-09-28 10:27:33 UTC
Permalink
Post by Uwe Rathmann
I'm worried about curves consisting of millions of points. They need to
be mapped to target coordinates and painted afterwords each time the plot
needs to be refreshed. Is it possible to pass these points via an HTML
based API with an acceptable performance ?
You have a valid point as I did not expect plots to be a major performance issue.
I don't think anyone can make performance promises at this point but I would also not expect it
to perform as fast as the current pipeline. On the other hand, being able to draw plot charts,
within Qt Quick was a major reason for adding this API in the first place.

I also get the feeling that embedding Qt Quick inside Widgets might not be as straight forward as I thought,
so I second Samuel's suggestion that just using your existing drawing code with a QImage might be the way to go.
Post by Uwe Rathmann
Post by j***@nokia.com
This should be ideal for graph plotting within Qt Quick as is
already demonstrated by the examples.
I checked a Qt 4.8 snapshot, but was not able to identify what example it
is ?
I was referring to the labs project in my previous mail. Not official examples.


Regards,
Jens Bache-Wiig
Uwe Rathmann
2011-09-28 11:52:38 UTC
Permalink
Post by j***@nokia.com
You have a valid point as I did not expect plots to be a major
performance issue. I don't think anyone can make performance promises at
this point but I would also not expect it to perform as fast as the
current pipeline. On the other hand, being able to draw plot charts,
within Qt Quick was a major reason for adding this API in the first place.
Obviously you had business charts for nice presentations in mind, but you
find completely different type of use cases in the scientific or
engineering world. Especially in combination with Qt/Embedded there are
many, many applications displaying results from measurements ( often in
"realtime" ) - you can find even YouTube videos demonstrating them. But
Qwt is also used in GIS applications - think about displaying a
spectrogram for the elevation of a whole continent.

Qwt is by far the oldest existing addon ( since Qt 1.1 in the 90s) and
has become the de-facto standard for plotting in the Qt world over the
years. I'm doing this package + all support since many years more or less
alone:

When plot charts were really one of the major reasons for introducing Qt
Quick I'm more than surprised, that nobody ever contacted me to find out
what the real world use cases for a plotting widget are.

Anyway ...
Post by j***@nokia.com
I also get the feeling that embedding Qt Quick inside Widgets might not
be as straight forward as I thought, so I second Samuel's suggestion
that just using your existing drawing code with a QImage might be the
way to go.
The plot canvas has its own backing store ( a QPixmap ) so - ignoring,
that I might loose any hardware acceleration - I could implement this
easily. But there are known use cases ( f.e. the oscilloscope ), where
this buffering needs to be turned off to get the required refresh rates.

So when I get it right this all means that if an application needs a Qwt
plot with certain performance requirements it needs the QPainter API and
therefore can't use Qt-Quick in the complete application - at least as
long as embedding a QWidget into a QML application is not supported.

For all other type of plots I could offer a second path, where the plot
is rendered via QPainter/C++ and QImage/QSGItem to something Qt Quick
compatible and the application could make use of Qt Quick ?

Isn't it possible to have an C++ API for the scene graph too - in the end
isn't it a problem of the API ( QML ) only and has nothing to do with the
new graphics pipeline ?

And what about the generation of documents ( mostly PDF ), what is one of
the key features of any good plotting library. Is this something I could
do with QML too or do I need to keep the QPainter based render code
because of this anyway ?

Uwe
Artur Souza (MoRpHeUz)
2011-09-28 12:57:51 UTC
Permalink
Post by Uwe Rathmann
When plot charts were really one of the major reasons for introducing Qt
Quick I'm more than surprised, that nobody ever contacted me to find out
what the real world use cases for a plotting widget are.
I think that when Jens was referring to the "HTML5 Canvas like
painting API" and not QtQuick itself when he talked about plot charts
as one of the major reasons to create an API.

Cheers,
--
-------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
-------------------------------------------------------
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------
g***@nokia.com
2011-09-28 12:58:18 UTC
Permalink
Post by Uwe Rathmann
Post by j***@nokia.com
You have a valid point as I did not expect plots to be a major
performance issue. I don't think anyone can make performance promises at
this point but I would also not expect it to perform as fast as the
current pipeline. On the other hand, being able to draw plot charts,
within Qt Quick was a major reason for adding this API in the first place.
Obviously you had business charts for nice presentations in mind, but you
find completely different type of use cases in the scientific or
engineering world. Especially in combination with Qt/Embedded there are
many, many applications displaying results from measurements ( often in
"realtime" ) - you can find even YouTube videos demonstrating them. But
Qwt is also used in GIS applications - think about displaying a
spectrogram for the elevation of a whole continent.
Qwt is by far the oldest existing addon ( since Qt 1.1 in the 90s) and
has become the de-facto standard for plotting in the Qt world over the
years. I'm doing this package + all support since many years more or less
When plot charts were really one of the major reasons for introducing Qt
Quick I'm more than surprised, that nobody ever contacted me to find out
what the real world use cases for a plotting widget are.
Anyway ...
There is a misunderstanding here. The Canvas API from HTML was added so that one could do some imperative painting from QML/Javascript without having to go to C++. It is effectively a QPainter API. Though it could be used to render a plot API, I would not compare it to Qwt. Qwt is infinitely much more. I'm sorry for the confusion.
Post by Uwe Rathmann
Post by j***@nokia.com
I also get the feeling that embedding Qt Quick inside Widgets might not
be as straight forward as I thought, so I second Samuel's suggestion
that just using your existing drawing code with a QImage might be the
way to go.
The plot canvas has its own backing store ( a QPixmap ) so - ignoring,
that I might loose any hardware acceleration - I could implement this
easily. But there are known use cases ( f.e. the oscilloscope ), where
this buffering needs to be turned off to get the required refresh rates.
So when I get it right this all means that if an application needs a Qwt
plot with certain performance requirements it needs the QPainter API and
therefore can't use Qt-Quick in the complete application - at least as
long as embedding a QWidget into a QML application is not supported.
And I do see us having this option available, long term. We think it is feasible, but have not implemented anything yet.

And please keep in mind that QPainter is NOT going away. Ever.
Post by Uwe Rathmann
For all other type of plots I could offer a second path, where the plot
is rendered via QPainter/C++ and QImage/QSGItem to something Qt Quick
compatible and the application could make use of Qt Quick ?
Isn't it possible to have an C++ API for the scene graph too - in the end
isn't it a problem of the API ( QML ) only and has nothing to do with the
new graphics pipeline ?
There is public API. The most relevant classes are:
http://doc.qt.nokia.com/qt5-snapshot/qsgitem.html
http://doc.qt.nokia.com/qt5-snapshot/qsgpainteditem.html

And if you want to implement your own scatter plot item you can use the raw scene graph API:
http://doc.qt.nokia.com/qt5-snapshot/qsgnode.html
http://doc.qt.nokia.com/qt5-snapshot/qsggeometry.html
http://doc.qt.nokia.com/qt5-snapshot/qsgmaterial.html

I would not be surprised if a scatter plot implemented using a geometry node would outperform QPainter
Post by Uwe Rathmann
And what about the generation of documents ( mostly PDF ), what is one of
the key features of any good plotting library. Is this something I could
do with QML too or do I need to keep the QPainter based render code
because of this anyway ?
I repeat: QPainter is NOT going away. Ever :)

-
Gunnar
j***@nokia.com
2011-09-28 13:26:02 UTC
Permalink
Thanks for clarifying that Gunnar. :)

Regards,
Jens Bache-Wiig
Post by g***@nokia.com
There is a misunderstanding here. The Canvas API from HTML was added so that one could do some imperative painting from QML/Javascript without having to go to C++. It is effectively a QPainter API. Though it could be used to render a plot API, I would not compare it to Qwt. Qwt is infinitely much more. I'm sorry for the confusion.
…
Post by g***@nokia.com
I repeat: QPainter is NOT going away. Ever :)
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Uwe Rathmann
2011-09-28 14:31:54 UTC
Permalink
Post by g***@nokia.com
And I do see us having this option available, long term. We think it is
feasible, but have not implemented anything yet.
And please keep in mind that QPainter is NOT going away. Ever.
Thanks for pointing this out once more - even if I already knew this from
previous threads.

But Qwt is a library - it doesn't want decide what is best for the
application. The fact, that certain plots can't be done with QML easily
( or at all ) doesn't mean, that other plots shouldn't be done in QML.

And even worse: a Qwt plot consists of items stacked in z order ( like in
the QGraphicsView framework ). Some of them might be very heavy ( curves
with many points ) - others might be simple custom items ( f.e a
watermark ) that could be implemented perfectly with QML in application
code. Both could be displayed on the same plot.
Post by g***@nokia.com
I repeat: QPainter is NOT going away. Ever :)
Qwt/QPainter is also not going away - ever. The development of Qwt/
QPainter will be continued not only maintained - maybe also ever. But
this is not the answer when users are pushing me for QML support in Qwt.

When there is a new key technology in Qt I'd like to support - not to
ignore - it. But when the design doesn't give 3rd party libraries a
chance to do so you should be aware, that this might result in 2
different Qt ecosystems.

Uwe
Uwe Rathmann
2011-09-28 15:09:57 UTC
Permalink
Hi Gunnar,
Post by g***@nokia.com
http://doc.qt.nokia.com/qt5-snapshot/qsgitem.html
http://doc.qt.nokia.com/qt5-snapshot/qsgpainteditem.html
And if you want to implement your own scatter plot item you can use the
raw scene graph API: http://doc.qt.nokia.com/qt5-snapshot/qsgnode.html
http://doc.qt.nokia.com/qt5-snapshot/qsggeometry.html
http://doc.qt.nokia.com/qt5-snapshot/qsgmaterial.html
Great, this seems to be what I was asking for - almost perfect because
QSGPaintedItem offers me a way to share the same render code for
Scenegraph, QWidget and generating PDF documents.

I don't care much about using QPainter or Scenegraph ( I prefer the
faster one ) it's more about how to mix C++ and QML written stuff into
the same scene.

Thank a lot for your patience,

Uwe
Michael Olbrich
2011-09-28 09:19:46 UTC
Permalink
Post by j***@nokia.com
I would not be too concerned as we will make it possible to embed Qt Quick inside normal QWidgets,
as is already fairly easy to do with Qt Quick 1. Note that we are going to ship Qt5 with an HTML5 Canvas like painting API.
http://qt.gitorious.org/qt-labs/qmlcanvas
This should be ideal for graph plotting within Qt Quick as is already demonstrated by the examples.
I would suggest that you implement the plotting charts in Qt Quick itself and simply embed your Qt Quick elements in a Wrapper Widget.
This should not add much extra effort apart from forwarding the API.
Painting in JavaScript? We just introduced declarative GUIs with WML for a
reason. This may be ok for smaller stuff, but unless it performs
significantly better than any Canvas API current browsers provide, then
things like the heartbeat plot from the Qt Embedded Widgets demo won't be
possible. Not on embedded hardware anyways.

Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Alexis Menard
2011-09-28 16:39:35 UTC
Permalink
Post by g***@nokia.com
Post by Alexis Menard
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.
Post by g***@nokia.com
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.
Post by g***@nokia.com
Post by Alexis Menard
- 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.
Post by g***@nokia.com
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.
Post by g***@nokia.com
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.
Post by g***@nokia.com
Post by Alexis Menard
- 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
Post by g***@nokia.com
Post by Alexis Menard
- 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).
Post by g***@nokia.com
Post by Alexis Menard
- 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.
Post by g***@nokia.com
Post by Alexis Menard
- 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.
https://bugreports.qt.nokia.com/browse/QTBUG-21697
It has been fixed before I pushed my merge request.
Post by g***@nokia.com
Post by Alexis Menard
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
Post by g***@nokia.com
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.
Post by g***@nokia.com
best regards,
Gunnar
Post by Alexis Menard
Post by l***@nokia.com
Post by Thiago Macieira
Post by g***@nokia.com
Post by Thiago Macieira
I'd also like to see a commitment to reaching feature parity and
platform
Post by Thiago Macieira
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 :)
Post by Thiago Macieira
I'm working on QUrl and I intend to provide that commitment when I ask that my
code be merged.
Post by g***@nokia.com
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.
Post by g***@nokia.com
Post by Thiago Macieira
- 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.
Post by g***@nokia.com
Post by Thiago Macieira
- 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
Post by Thiago Macieira
Post by g***@nokia.com
Post by Thiago Macieira
- 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
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Samuel Rødal
2011-09-28 07:55:25 UTC
Permalink
Post by Alexis Menard
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).
A wrapper to embed a QWindow in a QWidget should probably be
standardized and included in QtWidgets. Also saving and restoring
QWindow geometry sounds like a valid use case on desktop, could you make
a task for that?
Post by Alexis Menard
- 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?
I don't see why we wouldn't want to support shortcuts still, either
through the existing QShortcut API in QtWidgets or modified to not have
QWidget dependencies in QtGui. Desktop applications still need those :)
Post by Alexis Menard
- 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).
Might be a bug in the QPA or platform plugin code?

Note that some of the bugs / missing features are just things we haven't
gotten around to yet. Although I understand there is some pain involved
at the current state, it's great if people give Qt 5 a try and create
bug reports / feature requests for what's needed. Of course patches are
more than welcome as well, hopefully that process will be a lot smoother
when Open Governance goes live.

--
Samuel
Alexis Menard
2011-09-28 16:45:41 UTC
Permalink
Post by Samuel Rødal
Post by Alexis Menard
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).
A wrapper to embed a QWindow in a QWidget should probably be
standardized and included in QtWidgets. Also saving and restoring
QWindow geometry sounds like a valid use case on desktop, could you make
a task for that?
https://bugreports.qt.nokia.com/browse/QTBUG-21738
Post by Samuel Rødal
Post by Alexis Menard
- 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?
I don't see why we wouldn't want to support shortcuts still, either
through the existing QShortcut API in QtWidgets or modified to not have
QWidget dependencies in QtGui. Desktop applications still need those :)
+1
Post by Samuel Rødal
Post by Alexis Menard
- 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).
Might be a bug in the QPA or platform plugin code?
Note that some of the bugs / missing features are just things we haven't
gotten around to yet. Although I understand there is some pain involved
at the current state, it's great if people give Qt 5 a try and create
bug reports / feature requests for what's needed. Of course patches are
more than welcome as well, hopefully that process will be a lot smoother
when Open Governance goes live
--
Samuel
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
jjDaNiMoTh
2011-09-06 07:56:10 UTC
Permalink
2011/9/5 <***@nokia.com>:
[cut]
Post by l***@nokia.com
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.
When you talk about "Linux", do you refer to some arch in particular?

I mean, Linux runs on ppc, but V8 (other thread) currently not, so I
thought that the focus will stay on Linux (X11 and Wayland), Mac and
Win on Intel 32 and 64 bit processors.

Am I right or the architecture doesn't matter at this level ?

Thanks
l***@nokia.com
2011-09-06 08:28:18 UTC
Permalink
Post by jjDaNiMoTh
[cut]
Post by l***@nokia.com
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.
When you talk about "Linux", do you refer to some arch in particular?
I mean, Linux runs on ppc, but V8 (other thread) currently not, so I
thought that the focus will stay on Linux (X11 and Wayland), Mac and
Win on Intel 32 and 64 bit processors.
Am I right or the architecture doesn't matter at this level ?
OS and CPU architecture are to a large extent orthogonal. In terms of OS
we said Linux (X11 and Wayland), Mac and Windows.

In terms of the CPU architecture, we're almost everybody is currently
using x86, x64 or arm. To get all of Qt (including QML), other
architectures will need a working V8. Mips will get that soon, but I don't
know of other architectures being worked on right now.

Cheers,
Lars
Harri Porten
2011-09-06 10:00:41 UTC
Permalink
Post by l***@nokia.com
Post by Thiago Macieira
- 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...).
It is. But besides technicalities of the (open) development model the
bigger issue I see is with gaps opening up. If external people and
companies are faced with their favourite platform lagging behind too much
(not compiling, not working at all) the motiviation to follow will be
reduced dramatically. That's more of a psychological problem than a
technical one. So Nokia has to be careful with pacing ahead and creating
facts in a way that makes potential followers simple resignate.

Harri.
l***@nokia.com
2011-09-06 10:20:38 UTC
Permalink
Post by Harri Porten
Post by l***@nokia.com
Post by Thiago Macieira
- 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...).
It is. But besides technicalities of the (open) development model the
bigger issue I see is with gaps opening up. If external people and
companies are faced with their favourite platform lagging behind too much
(not compiling, not working at all) the motiviation to follow will be
reduced dramatically. That's more of a psychological problem than a
technical one. So Nokia has to be careful with pacing ahead and creating
facts in a way that makes potential followers simple resignate.
Yes. And there is work ongoing inside Nokia to get the Windows port up to
speed again.

Cheers,
Lars
g***@nokia.com
2011-09-12 08:40:47 UTC
Permalink
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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 widgets along with a number of currently less actively developed modules into their own libraries, in accordance with the module maturity list we published earlier this year and in line with Lars' blog about the intent of Qt 5. The over all goal is to simplify our graphics stack, minimize our platform/device dependent layer (lighthouse integration) and make sure QML and OpenGL are prime citizens in Qt 5.
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.
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).
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.
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to <QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this for you. Run it in the root directory and you are done.
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx which integrates tightly with lighthouse. To keep changes to existing code minimal, we decided to keep the existing libQtOpenGL classes pretty much as is without any changes, and rather introduce new classes in QtGui for the classes we wanted.
- Printing support has been moved into its own library, libQtPrintSupport. We have a long term plan of creating a better printing API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we have spent some effort in removing the dependency on the current API's from the "Qt essentials". The API is unchanged.
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack simpler to maintain and to have smaller footprint.
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue and QJSEngine classes in libQtDeclarative)
- In new projects, see if you can use OpenGL functionality in QtGui instead of libQtOpenGL.so
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes and add widgets/script/qtquick1 to your .pro files
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone. If you have further questions, don't hesitate to ask
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Sylvain Pointeau
2011-09-12 12:14:29 UTC
Permalink
Hi,

I am wondering why you suggested to use V8 instead of QtScript?
is it a module that will be dropped in a near future?

Best regards,
Sylvain
Post by g***@nokia.com
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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
widgets along with a number of currently less actively developed modules
into their own libraries, in accordance with the module maturity list we
published earlier this year and in line with Lars' blog about the intent of
Qt 5. The over all goal is to simplify our graphics stack, minimize our
platform/device dependent layer (lighthouse integration) and make sure QML
and OpenGL are prime citizens in Qt 5.
Post by g***@nokia.com
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.
Post by g***@nokia.com
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).
Post by g***@nokia.com
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.
Post by g***@nokia.com
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to
<QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this
for you. Run it in the root directory and you are done.
Post by g***@nokia.com
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx
which integrates tightly with lighthouse. To keep changes to existing code
minimal, we decided to keep the existing libQtOpenGL classes pretty much as
is without any changes, and rather introduce new classes in QtGui for the
classes we wanted.
Post by g***@nokia.com
- Printing support has been moved into its own library,
libQtPrintSupport. We have a long term plan of creating a better printing
API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we
have spent some effort in removing the dependency on the current API's from
the "Qt essentials". The API is unchanged.
Post by g***@nokia.com
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack
simpler to maintain and to have smaller footprint.
Post by g***@nokia.com
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue
and QJSEngine classes in libQtDeclarative)
Post by g***@nokia.com
- In new projects, see if you can use OpenGL functionality in QtGui
instead of libQtOpenGL.so
Post by g***@nokia.com
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes
and add widgets/script/qtquick1 to your .pro files
Post by g***@nokia.com
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone. If
you have further questions, don't hesitate to ask
Post by g***@nokia.com
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
g***@nokia.com
2011-09-12 12:56:40 UTC
Permalink
Post by Sylvain Pointeau
Hi,
I am wondering why you suggested to use V8 instead of QtScript?
is it a module that will be dropped in a near future?
There is already a JavaScript interpreter inside the QtBase repository, so why pull in another one if you don't have too?
The QtScript module will not be going away, but as it looks today, we will not be investing heavily into it either.

-
Gunnar
Post by Sylvain Pointeau
Best regards,
Sylvain
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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 widgets along with a number of currently less actively developed modules into their own libraries, in accordance with the module maturity list we published earlier this year and in line with Lars' blog about the intent of Qt 5. The over all goal is to simplify our graphics stack, minimize our platform/device dependent layer (lighthouse integration) and make sure QML and OpenGL are prime citizens in Qt 5.
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.
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).
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.
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to <QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this for you. Run it in the root directory and you are done.
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx which integrates tightly with lighthouse. To keep changes to existing code minimal, we decided to keep the existing libQtOpenGL classes pretty much as is without any changes, and rather introduce new classes in QtGui for the classes we wanted.
- Printing support has been moved into its own library, libQtPrintSupport. We have a long term plan of creating a better printing API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we have spent some effort in removing the dependency on the current API's from the "Qt essentials". The API is unchanged.
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack simpler to maintain and to have smaller footprint.
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue and QJSEngine classes in libQtDeclarative)
- In new projects, see if you can use OpenGL functionality in QtGui instead of libQtOpenGL.so
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes and add widgets/script/qtquick1 to your .pro files
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone. If you have further questions, don't hesitate to ask
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Sylvain Pointeau
2011-09-12 13:04:27 UTC
Permalink
Hi,

QtScript should be using V8 and provide all the facilities of binding
QtObjects...
(it is using JavascriptCore if I remember well correct?)
V8 is another story, it requires a lot more stuff from the development....

What is the other Javascript interpreter you mentioned?

Best regards,
Sylvain
Post by g***@nokia.com
Post by Sylvain Pointeau
Hi,
I am wondering why you suggested to use V8 instead of QtScript?
is it a module that will be dropped in a near future?
There is already a JavaScript interpreter inside the QtBase repository, so
why pull in another one if you don't have too?
The QtScript module will not be going away, but as it looks today, we will
not be investing heavily into it either.
-
Gunnar
Post by Sylvain Pointeau
Best regards,
Sylvain
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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
widgets along with a number of currently less actively developed modules
into their own libraries, in accordance with the module maturity list we
published earlier this year and in line with Lars' blog about the intent of
Qt 5. The over all goal is to simplify our graphics stack, minimize our
platform/device dependent layer (lighthouse integration) and make sure QML
and OpenGL are prime citizens in Qt 5.
Post by Sylvain Pointeau
Post by g***@nokia.com
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.
Post by Sylvain Pointeau
Post by g***@nokia.com
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).
Post by Sylvain Pointeau
Post by g***@nokia.com
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.
Post by Sylvain Pointeau
Post by g***@nokia.com
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to
<QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this
for you. Run it in the root directory and you are done.
Post by Sylvain Pointeau
Post by g***@nokia.com
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx
which integrates tightly with lighthouse. To keep changes to existing code
minimal, we decided to keep the existing libQtOpenGL classes pretty much as
is without any changes, and rather introduce new classes in QtGui for the
classes we wanted.
Post by Sylvain Pointeau
Post by g***@nokia.com
- Printing support has been moved into its own library,
libQtPrintSupport. We have a long term plan of creating a better printing
API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we
have spent some effort in removing the dependency on the current API's from
the "Qt essentials". The API is unchanged.
Post by Sylvain Pointeau
Post by g***@nokia.com
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack
simpler to maintain and to have smaller footprint.
Post by Sylvain Pointeau
Post by g***@nokia.com
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue
and QJSEngine classes in libQtDeclarative)
Post by Sylvain Pointeau
Post by g***@nokia.com
- In new projects, see if you can use OpenGL functionality in QtGui
instead of libQtOpenGL.so
Post by Sylvain Pointeau
Post by g***@nokia.com
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes
and add widgets/script/qtquick1 to your .pro files
Post by Sylvain Pointeau
Post by g***@nokia.com
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone. If
you have further questions, don't hesitate to ask
Post by Sylvain Pointeau
Post by g***@nokia.com
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
a***@nokia.com
2011-09-13 01:51:20 UTC
Permalink
Hi,

On 12/09/2011, at 11:04 PM, ext Sylvain Pointeau wrote:

QtScript should be using V8 and provide all the facilities of binding QtObjects...
(it is using JavascriptCore if I remember well correct?)

While this would be true in an ideal world, after much prototyping it was decided that porting the entire QtScript API to V8 and preserving its exact semantics was simply not possible. As a compromise, we have left the QtScript module untouched to preserve 100% compatibility for existing applications, and introduced a parallel API against V8 (the QJS* classes) that is similar enough that we expect most applications - and almost all new applications - to be able to move to it instead.

While the V8 library itself is in QtBase, the QJS* convenience API is in QtDeclarative, although it may be moved prior to the release of Qt 5 (see the lengthy "QML/JS engine in QtCore?" thread).

Cheers,

Aaron

V8 is another story, it requires a lot more stuff from the development....

What is the other Javascript interpreter you mentioned?

Best regards,
Sylvain
Post by Sylvain Pointeau
Hi,
I am wondering why you suggested to use V8 instead of QtScript?
is it a module that will be dropped in a near future?
There is already a JavaScript interpreter inside the QtBase repository, so why pull in another one if you don't have too?
The QtScript module will not be going away, but as it looks today, we will not be investing heavily into it either.

-
Gunnar
Post by Sylvain Pointeau
Best regards,
Sylvain
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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 widgets along with a number of currently less actively developed modules into their own libraries, in accordance with the module maturity list we published earlier this year and in line with Lars' blog about the intent of Qt 5. The over all goal is to simplify our graphics stack, minimize our platform/device dependent layer (lighthouse integration) and make sure QML and OpenGL are prime citizens in Qt 5.
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.
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).
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.
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to <QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this for you. Run it in the root directory and you are done.
- There is a new suite of OpenGL classes inside QtGUI, named QOpenGLXxx which integrates tightly with lighthouse. To keep changes to existing code minimal, we decided to keep the existing libQtOpenGL classes pretty much as is without any changes, and rather introduce new classes in QtGui for the classes we wanted.
- Printing support has been moved into its own library, libQtPrintSupport. We have a long term plan of creating a better printing API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951<http://bugreports.qt.nokia.com//browse/QTBUG-19951>, so we have spent some effort in removing the dependency on the current API's from the "Qt essentials". The API is unchanged.
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack simpler to maintain and to have smaller footprint.
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript. (QJSValue and QJSEngine classes in libQtDeclarative)
- In new projects, see if you can use OpenGL functionality in QtGui instead of libQtOpenGL.so
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes and add widgets/script/qtquick1 to your .pro files
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone. If you have further questions, don't hesitate to ask
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Sylvain Pointeau
2011-09-13 08:31:47 UTC
Permalink
Post by a***@nokia.com
As a compromise, we have left the QtScript module untouched to preserve
100% compatibility for existing applications, and introduced
Post by a***@nokia.com
a parallel API against V8 (the QJS* classes) that is similar enough that we
expect most applications - and almost all new applications -
Post by a***@nokia.com
to be able to move to it instead.
Hi Aaron,

ok thank you for the clarification. I think the message would have been
better to use the new V8 Qt bridge instead of linking directly with V8
(which is a massive work).

Please could you point me on some documentation for the new JS bridge? I
have googled but nothing.

Best regards,
Sylvain
Sylvain Pointeau
2011-09-13 09:04:04 UTC
Permalink
Post by Sylvain Pointeau
ok thank you for the clarification. I think the message would have been
better to use the new V8 Qt bridge instead of linking directly with V8
(which is a massive work).
Reading again the email from Gunnar, he told exactly that but I
misunderstood. My apologies.
Gábor Lehel
2011-09-13 08:42:53 UTC
Permalink
Post by a***@nokia.com
Hi,
QtScript should be using V8 and provide all the facilities of binding QtObjects...
(it is using JavascriptCore if I remember well correct?)
While this would be true in an ideal world, after much prototyping it was
decided that porting the entire QtScript API to V8 and preserving its exact
semantics was simply not possible.  As a compromise, we have left the
QtScript module untouched to preserve 100% compatibility for existing
applications, and introduced a parallel API against V8 (the QJS* classes)
that is similar enough that we expect most applications - and almost all new
applications - to be able to move to it instead.
Keeping 100% compatibility is a requirement even with the break to Qt5?
Post by a***@nokia.com
While the V8 library itself is in QtBase, the QJS* convenience API is in
QtDeclarative, although it may be moved prior to the release of Qt 5 (see
the lengthy "QML/JS engine in QtCore?" thread).
Cheers,
Aaron
V8 is another story, it requires a lot more stuff from the development....
What is the other Javascript interpreter you mentioned?
Best regards,
Sylvain
Post by g***@nokia.com
Post by Sylvain Pointeau
Hi,
I am wondering why you suggested to use V8 instead of QtScript?
is it a module that will be dropped in a near future?
There is already a JavaScript interpreter inside the QtBase repository, so
why pull in another one if you don't have too?
The QtScript module will not be going away, but as it looks today, we will
not be investing heavily into it either.
-
Gunnar
Post by Sylvain Pointeau
Best regards,
Sylvain
The merge will happen tomorrow morning, Oslo time.
Post by g***@nokia.com
Hi,
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
widgets along with a number of currently less actively developed modules
into their own libraries, in accordance with the module maturity list we
published earlier this year and in line with Lars' blog about the intent of
Qt 5. The over all goal is to simplify our graphics stack, minimize our
platform/device dependent layer (lighthouse integration) and make sure QML
and OpenGL are prime citizens in Qt 5.
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.
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).
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.
We're expecting to merge into master in 1-2 weeks time.
What are the changes in practice?
- code that use widgets need to add "QT += widgets" in their .pro file
- code that includes <QtGui/QLabel> or similar needs to be updated to
<QtWidgets/QLabel>. The helper script "fixqt4headers" in QTDIR/bin does this
for you. Run it in the root directory and you are done.
- There is a new suite of OpenGL classes inside QtGUI, named
QOpenGLXxx which integrates tightly with lighthouse. To keep changes to
existing code minimal, we decided to keep the existing libQtOpenGL classes
pretty much as is without any changes, and rather introduce new classes in
QtGui for the classes we wanted.
- Printing support has been moved into its own library,
libQtPrintSupport. We have a long term plan of creating a better printing
API, covered inhttps://bugreports.qt.nokia.com//browse/QTBUG-19951, so we
have spent some effort in removing the dependency on the current API's from
the "Qt essentials". The API is unchanged.
Can I expect any performance changes?
- No. This is about removing a large chunk of code to make our stack
simpler to maintain and to have smaller footprint.
What can I plan for?
- In new projects, see if you can use QML 2 instead of QWidgets.
- In new projects, see if you can use QML 2 instead of QML 1.
- In new projects, see if you can use V8 instead of QtScript.
(QJSValue and QJSEngine classes in libQtDeclarative)
- In new projects, see if you can use OpenGL functionality in QtGui
instead of libQtOpenGL.so
What does this means for you right away?
- If you upgrade to Qt5 with refactor, you need to update the includes
and add widgets/script/qtquick1 to your .pro files
What does this means long term?
- None of the existing libraries
I hope this transition will be as painless as possible for everyone.
If you have further questions, don't hesitate to ask
-
Gunnar
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Work is punishment for failing to procrastinate effectively.
Olivier Goffart
2011-09-13 09:09:35 UTC
Permalink
Post by Gábor Lehel
Post by a***@nokia.com
Hi,
QtScript should be using V8 and provide all the facilities of binding QtObjects...
(it is using JavascriptCore if I remember well correct?)
While this would be true in an ideal world, after much prototyping it was
decided that porting the entire QtScript API to V8 and preserving its
exact semantics was simply not possible. As a compromise, we have left
the QtScript module untouched to preserve 100% compatibility for
existing applications, and introduced a parallel API against V8 (the
QJS* classes) that is similar enough that we expect most applications -
and almost all new applications - to be able to move to it instead.
Keeping 100% compatibility is a requirement even with the break to Qt5?
Yes, keeping as much source compatibility as possible, in order to make
possible to upgrade projects with millions of lines of code.
Stephen Kelly
2011-09-14 20:13:52 UTC
Permalink
Post by g***@nokia.com
The merge will happen tomorrow morning, Oslo time.
The refactor branch should be merged again. There is one commit in the
refactor branch which is not merged into master, though it has been cherry
picked. Tools like gitk then show that refactor has not been merged into
master.
l***@nokia.com
2011-09-14 20:21:41 UTC
Permalink
Post by Stephen Kelly
Post by g***@nokia.com
The merge will happen tomorrow morning, Oslo time.
The refactor branch should be merged again. There is one commit in the
refactor branch which is not merged into master, though it has been cherry
picked. Tools like gitk then show that refactor has not been merged into
master.
I don't see this. Yes we have two merges close to each other, but gitk
shows the history just fine.

Cheers,
Lars
Stephen Kelly
2011-09-14 20:50:58 UTC
Permalink
Post by l***@nokia.com
Post by Stephen Kelly
Post by g***@nokia.com
The merge will happen tomorrow morning, Oslo time.
The refactor branch should be merged again. There is one commit in the
refactor branch which is not merged into master, though it has been cherry
picked. Tools like gitk then show that refactor has not been merged into
master.
I don't see this. Yes we have two merges close to each other, but gitk
shows the history just fine.
Cheers,
Lars
***@hal:~/dev/src/qtbase{master}$ git branch --contains origin/refactor
***@hal:~/dev/src/qtbase{master}$ git branch --contains origin/refactor^
* master

Also run gitk origin/refactor and compare the branches metadata for the
branch and the commit before it.
l***@nokia.com
2011-09-15 06:46:47 UTC
Permalink
Looked again, still can't see a problem.

Cheers,
Lars
Post by Stephen Kelly
Post by l***@nokia.com
Post by Stephen Kelly
Post by g***@nokia.com
The merge will happen tomorrow morning, Oslo time.
The refactor branch should be merged again. There is one commit in the
refactor branch which is not merged into master, though it has been cherry
picked. Tools like gitk then show that refactor has not been merged into
master.
I don't see this. Yes we have two merges close to each other, but gitk
shows the history just fine.
Cheers,
Lars
origin/refactor
origin/refactor^
* master
Also run gitk origin/refactor and compare the branches metadata for the
branch and the commit before it.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Stephen Kelly
2011-09-15 11:15:36 UTC
Permalink
Post by l***@nokia.com
Looked again, still can't see a problem.
Cheers,
Lars
Do you get this output?

$ git rev-parse origin/refactor
e3ea41e21af96e6e41936421188139e3b933c859

Do you get this:

$ git branch --contains origin/refactor
$ git branch --contains origin/refactor^
* master

Or this:

$ git branch --contains origin/refactor
* master
$ git branch --contains origin/refactor^
* master

?

I get the first one. If you get the second one, it might be that it is
already merged into whatever clone you're using.

I'm using git://gitorious.org/qt/qtbase.git

Thanks,

Steve.
Frederik Gladhorn
2011-09-15 11:46:15 UTC
Permalink
Hi Stepen,
Post by Stephen Kelly
Post by l***@nokia.com
Looked again, still can't see a problem.
Cheers,
Lars
Do you get this output?
$ git rev-parse origin/refactor
e3ea41e21af96e6e41936421188139e3b933c859
$ git branch --contains origin/refactor
$ git branch --contains origin/refactor^
* master
$ git branch --contains origin/refactor
* master
$ git branch --contains origin/refactor^
* master
?
I get the first one. If you get the second one, it might be that it is
already merged into whatever clone you're using.
I'm using git://gitorious.org/qt/qtbase.git
You are right, one patch was committed to refactor after the merge by
accident. But then also cherry-picked into master.
(5842e7e97efa80a9a8442e07f9898c32a4447102)

So no worries, refactor is completely contained in master and only master
should be used from now on.

Cheers
Frederik
Post by Stephen Kelly
Thanks,
Steve.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Stephen Kelly
2011-09-15 12:31:40 UTC
Permalink
Post by Frederik Gladhorn
Hi Stepen,
Hi,
Post by Frederik Gladhorn
You are right, one patch was committed to refactor after the merge by
accident. But then also cherry-picked into master.
(5842e7e97efa80a9a8442e07f9898c32a4447102)
Yes, I wrote that in my initial email.

My point was that when I checked if refactor had been merged into master the
'standard/normal' way, the tool told me it hadn't been, which is correct
because the extra commit was cherry-picked.

If you don't want to fix that, that's your call I guess, but it's a simple
fix.

Thanks,

Steve.
Loading...