[Accidentally sent in private to wrong recipient, so here again]
2011/10/7 Daniel Mendizabal <dan...@darhon.com>:
> ...
> But what happen now when new mobile phones come with Qt5 without QWidget
> support?
So I want to give my opinion about the QWidget vs QML discussion as
well. I already apologise for this lengthier post of mine, but I
followed several discussions with great interest - and concern.
For the actual question here: the answer has already been given:
QWidgets won't disappear. Period. At least not in Qt 5. Your Qt 4 code
will most likely compile on Qt 5 as before, as the promise is that the
transition Qt 4 to Qt 5 is supposed to be much less painful than it
was in some cases for Qt 3 to 4.
And that's that.
Now let me focus on some concerns of mine.
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
stack.
So I don't want to use it, I don't have to use it.
But recently it turned out that the whole paint stack, the "scene
graph", will be completely rewritten, to favour the QML architecture.
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
case I will have to link against all these JavaScript engine and
what-not libraries, just to display a "Hello World" in a QLineEdit,
implemented as some QML element in the background, interpreted by some
JavaScript engine, rendered by some OpenGL stack... but nicely shaded
maybe (which by the way I don't want at all, as I want my QLineEdit
look exactly as the "native" one!).
So QWidget has clearly become 2nd class and with regards to
performance "we" have to take what's left for us! At least that is my
impression from some discussions I followed.
So here are some points I'd like to throw in:
- I don't want to use any JavaScript in my code!
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
JavaScript!". And "don't use" also implies "I don't want to link
against any JavaScript library which I don't use".
Why? Because I want to be able to debug my whole GUI logic with the
same tools I develop my business logic! I don't want any "artificial"
wrapper objects which map JS values to C++ values and vice versa. And
even if my QWidget based classes would sit on top of this whole "QML
stack", running JavaScript under the hood I'd still suffer from
performance loss. For sure I would not gain any performance!
- I want performance!
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.
But with the current requirement that even the QWidget based apps now
need OpenGL support that means I cannot even run my apps in a virtual
machine such as VirtualBox on a Mac in a decent way (and yes, I AM
cross-developing a lot in VirtualBox, for both Windows and Linux)!
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!
Oh and yes, I also do OpenGL based applications, and I'd hate it to
see the widgets taking away valuable GPU cycles and introducing locks
by GL context-switching, simply because that damn button needs to have
its drop-shadow rendered nicely! (Yes, I am aware that OS X for
instance does nothing else - but Qt would again render ON TOP of that
with its own GL context etc.).
- 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!
- 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...
I wouldn't mind if the Qt Designer would create QML files under the
hood. Much the same way I don't care about the actual content of the
current UI files. As long as I would interface against a compiled C++
class in my own code! And there's type-safety, and not some "Oh let's
see what that string could be, let's cast it as an int at runtime..."
And if I rename a widget in Qt Designer I want to get a COMPILE error!
And not just a runtime error because the JavaScript/QML interpreter
figured only out by then.
- 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
JavaScript engine?
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
from the C++ without touching ANY JavaScript or wrapper?
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!
Now to be fair: I have not much experience with QML other than
studying some example code and running it! And I fully agree that my
points above might be a bit put into the extreme. But I wanted to
illustrate a point here, a perspective from the ordinary desktop
application engineer! And so far I am a bit surprised that there
hasn't been much discussion about the impact of QML onto ordinary
desktop applications on this list! Au contraire, it seems that more
people went like "Hooray, finally JavaScript for GUI development!"
What's so great about JavaScript anyway (what you couldn't do with
C++/Qt)? And "web apps", can't hear it anymore! If I wanted to write
such a thing then I'd grab some HTML5 editor and a JavaScript debugger
and have some smart people actually building the business logic in a
Java-based server backend!
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 ;)
Well, the the truth is I am very curious about the possibilities of
QML as well, and on mobile devices I strongly think that's the only
way to go! But mobile applications are fundamentally different than
desktop apps! And hey, I imagine even on the desktop QML applications
might make sense. Think "full-screen custom" games or information
systems. For sure I'll dig into QML as well!
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!
I am talking about that they are now placed on TOP of the "QML stack",
suffering from the performance penalty (and yes, I regard the
dependency on an OpenGL backend as a performance penalty!) and
extended memory footprint ("now plus a JavaScript engine + whatnot!")
and in exchange we gain... nothing!
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! 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
that!
Just to give you a real-world example: Adobe Flex! So I have
downloaded this "cross-platform" application from some photo studio,
as to design my photo book. And off course the first thing it does is
install its Flex runtime somewhere on the system (which later on
conflicts with another "Compressor" software by Apple due to
misbehaving read-write folder properties, but that's an entire
different story!). So anyway, I start it up on my shiny 2009 iMac...
and I start it up... and I start it up... finally! But what the... all
buttons look alien, the line edits react slughish, and DARE YOU
resizing the main window! IT SUCKS! It LOOKS BAD! It PERFORMS BAD! And
I HATE those custom-looking dialogs with drop-shadows everywhere! And
why the HELL does the toolbar have to be ANIMATED, when all I want is
to switch the tool! I give you a nano-second time, just switch that
damn tool! Don't fade in or out! YOU ARE WASTING MY PRECIOUS TIME! Now
here you got me started...! ;)
Well, the software was free and did its job.
Now usually I like to shoot at Apple fans (my favourite is the missing
Uninstaller, and don't even ask me how I like the Finder ;), but here
I am in the same row with them when I say: "It doesn't look like
Apple!" And usually I am not a big UI promoter - as long as it "just
looks native".
So here is my vote: Modularise Qt in such a way that the
"old-fashioned" QWidget approach works as before: no JavaScript
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!
I know at this point it's already too late I guess, the QML-ification
of Qt is already progressed to far. At least that had been my
expectation half a year ago... and who knows, maybe I AM one of the
very few people left trying to stick to the good old working
technology, and desktop apps as we know them are dying out. Every
application will bring along its own look and feel and usability
concepts and that's what people want (or the developers at least)...
then so be it!
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 ;)
Thank you,
Oliver
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
