[Qt5-feedback] Concern about removal of QWidget classes
thiago at kde.org
Fri Oct 7 15:48:22 CEST 2011
I'm taking your email as a vent and as a rant. And as such things go, it's
full of assumptions based on mistaken facts. Let me see if I can correct some
On Friday, 7 de October de 2011 14:27:20 Till Oliver Knoll wrote:
> A couple of months ago my impression was that QML will "live happily
> in parallel" to QWidgets. They are implemented in a separate "module",
> they link to their own required libraries, but that wouldn't concern
> me at all as a QWidget desktop application programmer. I would still
> happily link to my QtGui which would sit on top of some low-level
> QPainter-based libraries, which might also be used or not by the QML
That's more or less right and still remains so.
> But recently it turned out that the whole paint stack, the "scene
> graph", will be completely rewritten, to favour the QML architecture.
The Qt Quick stack was rewritten. Instead of Graphics View, it sits now on top
of the Scene Graph. The QWidget stack wasn't changed.
> And it turns out that for all these "fancy effects" we now need OpenGL
> support to get any descent performance. And what's more, the whole
> QWidget implementation will sit on top of all that. So in the worst
That's where you got it wrong. The QWidget implementation does not sit on top
of the QML-based Scene Graph. It still uses the old backing store, to the
point that there is a class called QBackingStore. The QWidget architecture is
That's good and that's bad: on the good side, it means what used to work will
continue to work. It was much less painful to make the migration to Qt 5 this
way. On the negative side, however, it means it got *none* of the performance
improvements that are going into the scene graph-based technologies.
> So here are some points I'd like to throw in:
You don't have to if you don't want, not now and not in the future.
But in the future it might become harder to avoid it. If you can code your UI
entirely on top of the scene graph without using the Qt Quick engine, you can.
> I chose Qt as a C++ framework for a reason! If I wanted to use a
> "non-native" language I'd chosen .Net or Java. I don't understand why
> everyone shouts "Hooray! Now we can code our GUI logic in
Because it's easier to use? Because designers can design the UI, instead of
engineers? There are many reasons to use it.
The fact that technologies like Python exist prove that there is a need for a
simpler way of developing things. And the fact that C and C++ continue to be
used means there's a need for native, bare-metal performance in some cases.
We're trying to marry both.
> - I want performance!
Ok, then you want OpenGL. You said you wanted performance, therefore you want
OpenGL for your UI. You *cannot* get better performance for graphical things
than to ask the GPU to do it for you the way the GPU does it best.
> I have tested one of my 4.7.3 Qt applications on a >10 year old HP
> laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM.
> Just for the fun of it. And it ran perfectly! The main window resized
> smoothly and overall GUI performance was very snappy. I am happy with
> this! And that is the benchmark I will refer to when testing any
> QWidget application on top of Qt 5.
Try going back to 4.4, before all the performance improvements targeting
mobile were in place. But the point is: we believe we have reached the limits
to what can be optimised in that architecture.
More improvements require OpenGL support and require doing it the OpenGL way
(retained state, like in the Scene Graph), not by bolting it under an
imperative painter. No wonder the raster engine in Qt 4 is better than the
> But even from a user perspective (I'd accept the argument that as a
> developer I should be able to invest into proper hardware) that means
> I am burning battery power of my laptop/tablet/phone each time the GPU
> starts cooking, simply because I resize my main window!
Yes. Fortunately, your GPU will be burning less battery power than the
equivalent operation on the CPU. So you have a net gain in battery
Do you really think that we'd be targeting OpenGL if it consumed more power?
Remember who is the main backer of the new architecture and what kind of
devices they sell.
> - I want native widgets!
> I want my application to look as natively as possible! Native, native,
> native! Can't repeat that enough. Even better: Use native widgets
> wherever possible (e.g. push buttons, drop-down boxes etc.). No
> rounded corners, no drop shadow, no textures where the OS window
> manager would not render them anyway!
You're calling for two separate things there. You want either native, or you
want no drop shadows and no rounded corners. If the native widgets have them,
asking not to have them means having non-native widgets.
I don't know how we're going to implement native widgets in the QML-based
> - I for sure don't want to hand-code any XML-like GUI files!
> We have Qt Designer for a reason! Editing GUI in a text file is sooo
> late century, you know! And if I want to programmatically define the
> GUI, then I want it to be blazing fast, means compiled. With a
> well-documented API, simple to use. Oh, we already have that, it's
> called Qt...
There's a Qt Quick Designer too.
Whether you're going to be able to interface with generated, type-safe C++
code is uncertain. Probably unlikely.
> - I want a small memory/disk footprint!
> A small application on a Mac (or Windows, can't remeber)I brought to
> about a little bit under 10 MBytes, linking to QtGui and QtCore (Cocoa
> 64 bit only, stock Qt 4.7 distribution). That is already a LOT! By
> modularising Qt even more - e.g. split the special QWidgets into a
> separate module than QtGui - I'd expect to bring this value to a even
> lower value. I am talking about a small GUI application. Now what if I
> would actually need to link against WebKit etc., just to get a decent
You're getting exactly that. The widgets are in QtWidgets.
The V8 engine isn't part of WebKit and doesn't require loading QtWebKit. You
load QtWebKit if you want to display web pages.
> I do understand that there is a "research" project on the way to bring
> "desktop widgets" to QML. QActions? Oh yes, we need to research that.
> Layout managers? Huh... yeah, we thought about that too, needs some
> more research. Signals/slots? Menues? Toolbars? Lists? And all this
Why did you put the word "research" in quotations? Did you mean to imply it's
not valid research? That it will never see the light of day? That you don't
care about it? I don't know if you realise it, but it also demeans the people
doing the research.
> Hey yes, EVENTUALLY we will be there. But my point is: we will be
> there WHERE WE ARE RIGHT NOW! Because the way the QWidget approach
> works in combination with Qt signals/slots and Qt Designer JUST ROCKS!
> And programmatically creating "dynamic GUIs" by adding menu entries,
> enabling/disabling widgets, making them in/visible, populating lists
> programmatically is almost a no-brainer with the wonderful Qt API!
No, we won't be right back where we are right now. We will have new
technologies, easier to develop with for people who are not as bright as you
are (but often have better grasp of UIs) and they will be properly hardware-
accelerated. We'll have properly separated the UI from the logic. We'll have
something sustainable for the next 5-10 years or more.
I appreciate that it just works for you today. And that's a testament to the
effort put in by the same engineers who are now telling you QML is the way
forward. However, you're failing to see the maintenance overhead that these
engineers have faced to keep the widgets working nicely for you. You're
failing to see that we've reached the limit of optimising them further. And if
you think this technology just rocks, you should be duly impressed by the new
It's no wonder: of course the proven technology you know is easier than the
technology you don't, yet to prove itself.
> Now to be fair: I have not much experience with QML other than
And this sentence should invalidate your entire email. Are you really crying
out against a technology you haven't given a chance?
> Why do browsers want to be able to execute native C code nowadays and
> become more and more of a "runtime environment" for I don't know what?
> And why are desktop toolkits so keen on bringing whole web browsers
> into their dialogs? (Not that I mind having a great QWebKit
> implementation available - IF I need it ;)
That's exactly what we're trying to do: bridge the two worlds, of native and
of interpreted, dynamic languages. The only difference is that we're not
betting exclusively on HTML 5, but instead providing a language suitable for
> But to summarise: as it appears to me now at least QWidgets have
> clearly become second class citisen. And I am NOT talking about that
> there won't be any new development, such as new widgets such as
> ribbons (God beware ;). I am perfeclty fine with "it is as good as it
> gets and we just reached that point". Some bugfixing here (yes, on Mac
> there are still some glitches here and there), and I'd be happy!
You're getting it. Just remember that the bugfixes won't be to little glitches
on Mac. More likely, they will be for crashes or really ugly issues.
Unless someone wants to take over maintainership and drive again development.
Remember that whoever wants to do this will have to keep the stability, so
maintainership can be revoked if too many regressions are introduced and not
fixed. In essence: we don't recommend doing this.
> I am talking about that they are now placed on TOP of the "QML stack",
That's a mistaken assumption. They are not.
> And don't be mad, I highly appreciate the work being done, but still I
> think this whole "QML desktop research" is a waste of time! There is
> nothing to gain except what we have already now! And I am HAPPY what
> we have now!
That's really offensive to the people doing it.
> Don't tell me that in the future it will be so much
> easier to animate my buttons, have rounded corners, glossy shiny
> effects... if the window manager doesn't render that, I don't WANT
Oh, but you're forgetting that the UIs of the future will be like that because
customers are demanding it and others are driving it! So you want to keep your
UIs as they are... Let's say you had kept them as they were 14 years ago.
Here's what it looked like:
So let me summarise: we cannot stop innovating.
> So here is my vote: Modularise Qt in such a way that the
> engine, no OpenGL dependency, just the clean C++ API with its blazing
> performance as we know it. And if I really want to use QML I just link
> to those libraries as needed - with all its fancy and shiny glory!
You've got it. But it will stay as it is. Look at that link above again. Now
place yourself in your 2016 shoes and look at your UIs of today.
> Thanks for those who actually read until here, and apologise again to
> those who skipped reading long time ago. ;) I just had to off-load
> here a few concerns, and a little bit frustration after pretty much
> exactly 10 years of Qt coding and promoting! I hope I started some
> CONSTRUCTIVE discussion, by starting with an admittedly somewhat
> extreme point ;)
Unfortunately, you lost time writing all of that based on mistaken
assumptions. If you had just taken the time to clarify first...
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20111007/847f786f/attachment.bin
More information about the Qt5-feedback