Hello Thiago, hello everyone,
I read all messages so far to this subject, but will reply to Thiago's
message only for now. It kind of sums it up anyway very nicely.
Post by Thiago MacieiraPost by Till Oliver Knoll...
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
mostly unchanged.
Okay then, glad I misinterpreted this. As Thomas already mentioned, I
had exactly this article in mind:
http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/
May I quote that specific paragraph:
"QPainter will still be available and is very useful for many things,
but it won’t be used for the main user interface. Qt will require
OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene
graph (not the scene graph on top of QWidgets as is currently done
with Qt 4)."
Now you tell me that QWidgets won't sit on top of the scene graph
(which requires OpenGL ES etc.) and I take your word for it. My
interpretation was different and based on that assumption my
impression was that in Qt 5 the "QWidget stack" would be merely put on
top of the new scene graph, dropping the "QPainter" approach
altogether - with all the necessary additional libraries.
Post by Thiago MacieiraPost by Till Oliver KnollI chose Qt as a C++ framework for a reason! ...
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.
Yes. Might be true for small applications, "weather apps" and sort of.
Post by Thiago MacieiraOk, then you want OpenGL. You said you wanted performance, therefore you want
OpenGL for your UI.
No. I want OpenGL to render MY stuff, and not getting into my way when
rendering the GUI.
I already mentioned that I am fully aware that these days window
managers such as on Mac OS X, Windows 7 (Vista) also use OpenGL. But
first off that's on an "OS level", that is highly optimised, whereas
the OpenGL rendering of Qt would be "on top of that", in "application
land". The window manager would have no influence on optimising that
(which I hope it does when painting its own widgets).
Well anyway, my point is that performance for drawing a few buttons
and rectangles is way enough available these days! Heck, we're talking
GIGAHertz these days, not Megahertz!
And updating the GUI in Qt was never a bottleneck for me.
Again, I am talking about "plain old desktop applications", with the
look and feel of the underlying OS.
Post by Thiago MacieiraYou *cannot* get better performance for graphical things
than to ask the GPU to do it for you the way the GPU does it best.
Well, agreed. My point was more that it is not necessary for my
desktop application needs. I fully agree with you that if you want to
do MORE effects with QML, then yes, it might be necessary to have
OpenGL support.
But let's not ride on the performance issue for too long, my
objections against QML are based more from a programming point of view
anyway.
Post by Thiago MacieiraPost by Till Oliver Knoll... 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
consumption.
... under the assumption that the CPU is using less or no power at all
in the meantime. Besides graphic performance is accelerated since
Window 3.1, for instance no CPU is wasting CPU cycles when drawing a
rectangle or a line! That's all being handled by dedicated chips on
the normal 2D graphic card, and the same argument with less power also
applies there I guess.
So no, I don't think that using your GPU would actually consume LESS
power than the combination CPU/2D graphic card. But let's not count
watts here either ;)
Post by Thiago MacieiraPost by Till Oliver Knoll- I want native widgets!
I want my application to look as natively as possible!
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.
No, my point is a different one: I want native look and feel! If the
native window manager decides to draw a nice shadow around every
dialog, then so be it! If the native window manager decides to draw
rounded corners around my main window - so be it! So I was NOT asking
for "no, I don't want to have drop-shadows or rounded corners", I was
asking to have widgets which EXACTLY (as closely as possible at least)
behave like the underlying window manager/OS would do! (And you can
extend this to anything beyond drop-shadows and rounded corners:
colour schemes, click-behaviour etc.)
Post by Thiago MacieiraI don't know how we're going to implement native widgets in the QML-based
world, though.
See what I mean? That's why I prefer to stay with the QWidget approach
for desktop applications.
Post by Thiago MacieiraPost by Till Oliver Knoll- I for sure don't want to hand-code any XML-like GUI files!
We have Qt Designer for a reason!
There's a Qt Quick Designer too.
Yes, I know that. My point was more aimed at the "pro argument" that
it is much easier to use declarative UI design. My point is "so what?"
I am not hand-coding anyway, so this is no use to me.
Agreed, animating stuff, drawing custom widgets etc. is indeed much
easier in QML. But to repeat: I don't want to animate, I don't want
custom widgets (and I am talking about the "ordinary" and typical user
interface elements such as buttons, comboboxes, not about "custom
widgets" such as graphs, stock tickers or what not).
So all this doesn't bring me any value.
Post by Thiago MacieiraWhether you're going to be able to interface with generated, type-safe C++
code is uncertain. Probably unlikely.
Well, I once visited a presentation of Adobe Flex. First they showed
some flashy pie charts and stuff. Really impressive. Agreed, with QML
you're getting there quicker, too!
But after the presentation developers asked: "So how do I bring the
data from the Flash world into our Java world?" I got sick from all
these type-casts, assumptions like "Yeah, this string is ALWAYS a
float, sure", weird JavaScript code just to get the value out of a
combobox etc. NO WAY!
Now yes, off course we're talking Flex here, and QML might or might
not be different. But when I looked at the Qt 4.7 examples with all
their JavaScript flying around, every foobar button in its own QML
file... how am I supposed to debug this!
So I like the SIMPLICITY of having all GUI elements of a dialog in my
UI file which gives my a nice C++ class with all it's typesafety (as
long as typesafety in C++ goes), I can access all this data without
typecasts from my own clean C++ class, I don't see ANY generated
code... NICE!
Post by Thiago MacieiraPost by Till Oliver Knoll- 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 ...
You're getting exactly that. The widgets are in QtWidgets.
Good! :)
Post by Thiago MacieiraThe V8 engine isn't part of WebKit and doesn't require loading QtWebKit. You
load QtWebKit if you want to display web pages.
There was some discussions recently about which JavaScript engine to
use. Either put it into QtCore (well, I am not complaining about an
extra 200 KBytes in QtCore) or - even worse - use the one from Webkit
(meaning you always have to link against a whole browser rendering
engine, just for a simple GUI application!).
So apparently the outcome was to use a separate "V8" JavaScript
engine, in its own library (separate from any Webkit - even though I'm
not sure whether that would mean having TWO JS engines in total - or
is it really the idea to rip out the JS engine implementation out of
Webkit? Or is Webkit using a separate JS library anyway? Don't know.
Post by Thiago MacieiraPost by Till Oliver KnollI do understand that there is a "research" project on the way to bring
"desktop widgets" to QML. ...
Why did you put the word "research" in quotations? Did you mean to imply it's
not valid research?
No, not at all! Sorry, but I had a specific mail in mind here which
was exactly mentioning that there would be a LOT of work to do, to
have the equivalent of QActions/Signals/Widgets of what we have today
already. And my mind was probably automatically think in "quotes",
without actually telling you the source of my "quote".
Really, I did not intend to put any other meaning behind my "'s,
except to mean that I was referring to some other posting here on the
list!
Post by Thiago MacieiraPost by Till Oliver KnollHey yes, EVENTUALLY we will be there. But my point is: we will be
there WHERE WE ARE RIGHT NOW! ...
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)
I have a pretty well-defined grasp of UIs, and I tell you, the people
you are referring to are probably the same people that are either
responsible for the "Nokia PC Suite" (which is used to synchronise
Nokia phones on Windows) or the mentioned "Photo album designer" done
in Flex, backed up by some marketing and PR guys.
Now I already gave an impression on how much - as a user of software,
not as a developer! - I could kick those peoples but! Really! That's
EXACTLY the reason I am objecting to QML on desktops so much!
Yes, let the designers draw some nice icons! Let a usability
professional decide on how many icons there maximum in the toolbar
should be or how many entries per menu. Let them decide about
USABILITY!
But for God's sake, don't let them near any coding of the user
interface! Don't let them think that if they were able to code some
website that they would do any good with "custom buttons", animating
windows and stuff and then you stumble over UI items not being
properly disabled/enabled, texts cut off because "Ups, the german
sentence is longer than the english one - but hey, we HAVE to have a
fixed size button here, because otherwise the texture wouldn't cover
the entire background"...
Seen that, been there, NOT going to do that!
Oh I am getting started here again! ;)
Post by Thiago Macieiraand they will be properly hardware-
accelerated.
Again, what we have so far doesn't need any hardware acceleration
other what we ALREADY HAVE! My Qt apps render nicely on Mac (with
drop-shadows added by the window manager) and they even perform on a
Pentium III - even on a recent KDE 4.7 on said Pentium III! (Off
course with most graphic effects turned off, but still impressive
looking).
Post by Thiago MacieiraWe'll have properly separated the UI from the logic. We'll have
something sustainable for the next 5-10 years or more.
Yes, but there would be so much more work in Qt which could be done:
- SOAP
- JSON
- C++ 11
- Document architecture (think "Abstraction of NSDocument" in Cococa)
- Extended gesture support
- OAuth2 support (agreed, that's also a no-brainer with the current Qt 4.7)
- Make sure Qt rocks with IPv6 (anyone checked that? Just saying...)
- Proper file monitoring support ("did the file xy change?")
Etc. etc. stuff like modularisation, THAT brings value for desktop development!
Again, I don't mind having a separate QML stack besides my QWidget approach.
Post by Thiago MacieiraI 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.
And I am very happy to fail in seeing that - after all that's my
number one reason to use a framework like Qt (even if I would only
develop on ONE platform ;)
Post by Thiago MacieiraYou're
failing to see that we've reached the limit of optimising them further.
Well, I did not say I was unhappy with the current performance of Qt widgets ;)
Post by Thiago MacieiraAnd if
you think this technology just rocks, you should be duly impressed by the new
one.
I am impressed with how easy you can animate stuff, add gradients... I
am just saying I don't need this for desktop development! I want
BORING widgets! ;)
Post by Thiago MacieiraPost by Till Oliver KnollNow 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?
Well, probably more experience than you might think! I am just saying
I studied the existing Qt 4.7 QML code and was NOT impressed! Why?
Because the whole UI logic was spread around in JavaScript, QML files
and some additional C++ code! Maintenance nightmare when it comes to
"large-scale" applications!
I ran the examples and was NOT impressed from a desktop perspective,
because I could not even resize the examples, the buttons looked
weird, and I did not get the point in animating rectangles and stuff.
However I WAS impressed how easy it seemed to populate lists of images
with feeds such as from Flickr. However I don't see why networking in
Qt should be not as easy as that, too, given a proper JSON parser (the
existing one QJson, works very well!)
Post by Thiago MacieiraThat's exactly what we're trying to do: bridge the two worlds, of native and
of interpreted, dynamic languages.
And I am saying that is exactly what I DON'T need in desktop apps! I
want ONE language. And for sure not an interpreted language such as
JavaScript, heck!
Post by Thiago MacieiraPost by Till Oliver KnollBut 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.
Well that's too bad then that QWidgets won't be fixed anymore! At
least not from Nokia, as it seems.
Post by Thiago MacieiraUnless someone wants to take over maintainership and drive again development.
That's my hope anyway.
Post by Thiago MacieiraRemember 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.
Well, that's true for pretty much every development, also new one. So
no reason to scare away people in fixing stuff.
Post by Thiago MacieiraPost by Till Oliver KnollI am talking about that they are now placed on TOP of the "QML stack",
That's a mistaken assumption. They are not.
Your word in my ears!
Post by Thiago MacieiraPost by Till Oliver KnollAnd 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.
I apologize. My frustration about loosing a GREAT Qt API was just
letting go I assume.
Again, I am not saying to drop QML! As long as it lives in PARALLEL to
QWidgets and I don't ever have to use it (unless I want to), then I am
PERFECTLY fine!
But re-inventing the wheel when trying to do desktop development with
QML (not QML itself!), so to speak, to come up with something we
already have, but just with more bads than goods (OpenGL dependency,
interpreted language under the hood, clumsy data exchange with
JavaScript, ...)., that is a waste of precious resources!
I mean you already hinted above that once you get on the scene graph
train there's hardly any way around dealing with JavaScript. And that
alone is a HUGE drawback for me!
But let's see, maybe I am wrong.
Post by Thiago MacieiraPost by Till Oliver KnollDon'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
that!
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.
http://www.linux-kongress.org/1997/kde_desktop.gif
So let me summarise: we cannot stop innovating.
No we can't. But also remember that the trend in UI is now in the
OTHER direction again, towards SIMPLER and MINIMALISTIC ways of
drawing stuff, see Mac OS X! The time of "Hey, KDE can draw wobbly
wobbly dialogs (but requires OpenGL support to do so)" is long time
over!
And Qt just performs fine (with QWidgets!) on todays hardware, so why worry?
Post by Thiago Macieira...
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.
There will be more "individually looking apps" and I will still want
to kick those people's butt for making apps which look different than
my Windows or Mac or KDE?
Post by Thiago MacieiraPost by Till Oliver KnollThanks for those who actually read until here, and apologise again to
those who skipped reading long time ago. ;)
Unfortunately, you lost time writing all of that based on mistaken
assumptions. If you had just taken the time to clarify first...
No, my point still stands: as long as I can code with Qt 5 without
touching any JavaScript/QML if I don't want to, I am perfectly happy!
I had reasons to believe that I would not be able to do so, but you
said otherwise. I have to take your word for that.
But I gave valid reasons why I don't want to use QML and fancy UI
design for desktop applications, both as a developer and a user! I
gave a concrete example - the Adobe Flex one - and maybe placed it a
bit too pointy, but bottom line is the performance there sucked big
time(1) and the user experience, well: "it just didn't fit into my
Mac!" Luckily it was a "one time usage" only...
(1) I am not saying that I am comparing Flex vs QML, but it is the
same paradigm and the same "misuse" potential is there.
Have a nice week-end all!
Cheers, Oliver
