Thoughts about Qt 5

Published Monday May 9th, 2011 | by

Qt 4.0 was released in June 2005, almost six years ago. A lot has changed in the software industry over these years. While application development back then happened mostly on desktop systems, mobile devices connected to the web have become increasingly popular. User interface technology has moved from static widgets to a fluid touch based experience. Since Qt 4.0 we have released seven minor versions of Qt to stay ahead of development needs, for example by releasing Qt Quick. Within the growing Qt user base, we have had a strong up-take and new needs from embedded and mobile app and UI developers.

To also, in the future, be a leading edge development framework across multiple industries, Qt needs to continue to renew itself. Qt 4 has been an evolution, and I have been thinking about what future Qt versions might look like from a technical perspective. Over the last years we have been working on laying the foundations for the next major release. I see Qt Quick, QML Scenegraph and Project Lighthouse– combined with an increased focus on Qt Webkit – as the foundation which we plan to use to move towards a new major release of Qt.

Given that Qt is moving into open governance mode in the upcoming months, I wanted to share my thinking with the Qt community in order to kick off the discussions about what I see as the technical architecture for Qt 5.

Objectives with next major version of Qt (Qt 5)

  • Make better use of the GPU, allowing you to create smooth (and accelerated) graphics performance even with limited resources;
  • Making your creation of advanced applications and UIs easier and faster (with QML and Javascript);
  • Make apps connected to the web be as powerful as possible, i.e. to embed and power up web content and services into any Qt app; and
  • Reduce the complexity and amount of code required to maintain and implement a port.

Qt 4.7 contains some legacy code that prevents us from making Qt as good as possible for creating next generation applications and UIs. While most parts are still very relevant to our developer base, some parts are also blocking our way in the 4.x frame.

Making it straightforward to move applications from Qt 4 to Qt 5

With Qt 5 we plan to make selected changes in the APIs and leave behind limitations from the past where required for the best of the future. For those of you that were with us for the transition of Qt 3 to Qt 4, we do not plan to repeat that difficult transition with Qt 5. To be explicit here – we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed. We will do everything to avoid breaking any fundamentals and to make it easy and very straightforward for the wide majority of applications to move from Qt 4 to Qt 5.

The initial thinking is that Qt 5 will focus on a small set of operating systems/platforms (i.e. platforms Wayland and X11 on Linux, Mac and Windows). The total number of platforms will depend on the community efforts invested as Qt moves into open governance mode. Other operating systems currently supported by Qt 4 (esp. commercial UNIX systems) will not be in focus for Nokia. The goal of the Qt 5 project is to offer the best possible functionality on each platform, implying that Qt will begin to offer more differentiated functionality on some OS’s, while still offering efficient re-use for the absolute majority of the code across platforms.

Developed in the open, together with you, with strong backing from Nokia

Another major change with Qt 5 will be in the development model. Qt 4 was mainly developed in-house in Trolltech and Nokia and the results were published to the developer community. Qt 5 we plan to develop in the open, as an open source project from the very start. There will not be any differences between developers working on Qt from inside Nokia or contributors from the outside.

If you want to involve yourself or your company in Qt 5 development, please join the Qt contributor summit in Berlin, June 16-18. This is the main place where we would like to discuss the plans and ideas we have for Qt 5.0 and 5.1 together with you. Some of us will also be at the Ubuntu developer summit this week and the MeeGo conference later this month.

Vision

Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.

With Qt 5 we should put Qt Quick into the center of Qt without being disruptive for existing code developed for Qt 4. It will rather be a restructuring that will allow us to change the way we will think about application development in the future.

While traditional Qt/C++ applications will continue to work with Qt 5, there will be some fundamental changes on how applications can and will be written.

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

While we propose keeping the QWidget based programming model and API set available for compatibility, long term we also see QML as the future for user interfaces on the desktop. The solution here will most likely be QML-based component sets that integrate with the native styling APIs on the desktop platforms.

Four big architectural changes:

  1. Re-architecture our graphics stack
    We will put Qt Quick and the QML Scenegraph into the center of our new graphics architecture. 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).
  2. Base all Qt ports on Lighthouse
    The Lighthouse project was started with the goal of providing a better way to abstract the window system integration than we currently are using. It’s now reaching maturity with Qt 4.8, and we intend on using it exclusively for all Qt ports in Qt 5.0.
  3. Modular repository structure
    A lot of this work has been done over the last weeks and you can see the results in the new modular Qt repositories. The modularization of Qt will facilitate and speed up the possibility to integrate contributions to Qt.
  4. Separate all QWidget related functionality into its own library
    While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

As you have seen from previous blog posts, the first three points have been worked on for quite some time and we’re starting the work on the last one right now. We do expect to have most of these changes done before August.

Qt Components and Qt Mobility will become more integral parts of the Qt platform and not be modules with a special status anymore.

Beta quality code available towards the end of 2011. Final release in 2012

Since we don’t believe we should change too many of Qt’s fundamentals, and the fact that we want to make it easy for existing applications to move to Qt 5 require us to be careful with the amount of changes we do to our existing code base. Many of the changes we are proposing and have started working on are about restructuring our code base into a new modular structure where every shared library lives in its own repository. We believe we should remove a few very rarely used APIs where keeping compatibility would block our way into the future. We think we will have beta quality code available towards the end of the year and final Qt 5.0 release some time during 2012.

Last week’s released Qt SDK with updates are planned to be used for the coming year to target Nokia Symbian and MeeGo devices. Qt 5.0 is focused around next generation application and UI development while still making it easy for apps developed with the Qt SDK to move to Qt 5.

Help us speed up the development

For those of you interested in some more details, here’s a link to a whitepaper describing some of the ideas in more detail. None of it is set in stone, but it reflects our current thinking.

You can also follow our work in the set of modular Qt repositories. We intend on keeping the master branch usable at all times on at least Linux with both Wayland and X11 (xcb lighthouse plugin). Work on getting things up and running on Mac and Windows has started, but it’ll probably take a little while before these ports become usable again.

We are all extremely excited about doing this renewal of Qt together with you. We believe that some features will not be fully in place in Qt 5.0 and will only come over time in subsequent releases, but we believe it will be possible to not have any significant feature regressions to Qt 4.8 (yes, we intend to release one more minor version in the Qt 4.x series within the next couple of months!). While developing Qt 5 we must do our very best to maintain source compatibility with Qt 4, so that moving your application over to Qt 5 will be as simple as possible. So if you want to help out or get involved yourself in Qt 5 development, why not meet up with us at the coming to the Qt Contributors Summit in Berlin this June.

UPDATE: Responses to Qt 5

Did you like this? Share it:
Bookmark and Share

Posted in Contributors, KDE, Qt

207 comments to Thoughts about Qt 5

jb says:

It is quite cool to see Qt moving on…

However:
“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.”
How will that work with native widgets and handle?

And how will the native widgets on Windows be rendered?

Thiago Macieira says:

@jb: that’s what the Qt Components for Desktop is supposed to figure out. If you look at the whitepaper, there’s some more information. Painting should be done either via the rasteriser or to an FBO. Then Scene Graph takes over and displays it.

Jens Bache-Wiig says:

jb: Qt on scenegraph already provides a QSGPaintedItem, with the option of rendering either directly to a framebuffer object or indirectly via a QImage . It gives you QPainter support on the scenegraph and a way to basically create a drop-in replacement for existing declarative c++ plugins. I have already ported my desktop widgets with native look and feel to the scenegraph without any major issues.

Paul Miller says:

I would love to see easy separation of the windowing “stuff” from the drawing “stuff”, to make it possible to use QImages/QPainters for drawing and I/O, without requiring a QApplication. In other words I don’t want to have to fire up a full-blown QApplication, with all the internal event loops, timers, signal handlers, host OS hooks, etc that happens along with it. This would allow me to use more of Qt when embedded inside other applications as plugins, so I can use Qt for my drawing/text layout/etc engine. This might not work on Unix though, since some of those things require a running X server, and I need to run stuff from the command-line. Don’t know if this is possible, but I always thought it a little weird that QImage/QPainter didn’t work in QtCore. But then, I write image processing applications where I have to do a lot of “off-line” rendering, and need cross-platform support for such things without running a windowed application. This comes from numerous conflicts encountered over the years when attempting to embed a QApplication inside Photoshop or other third-party hosts.

Maybe even a “give me everything based on a raster or OpenGL paint engine but don’t hook into the host OS event loops” compile mode.

Niels Ole Salscheider says:

Focusing on QML for all platforms is my biggest wish for Qt5, too.

Apart from that, it would be nice to see some parts of kdelibs’ core merged back to Qt given the functionality might be useful for all platforms.

I’m not sure if some other changes would make sense considering the upcoming c++0x.

jb says:

Well, reading the whitepaper, I don’t see how lighthouse can allocate a native widget and pass its handle around (winId() in Qt4)

“The fact that we are nowadays not using native child windows anymore also makes this approach a lot more feasible.”

But maybe the whitepaper is just not complete, and it will come around.

sroedal says:

@Paul: With lighthouse it’s possible to use the minimal platform plugin to use Qt Gui without any window system dependencies.

sztomi says:

Any plans to take advantage of C++0x features? Especially lambdas. Using lambdas in SLOTs would be awesome.

jb says:

@Jens Bache-Wiig: great, that’s really cool. I just wonder now about how to get a native handle to draw overlay on it :D

gunnar says:

jb: existing QWidgets will continue to render through backingstore / QPainter using the raster paint engine on Windows. The raster based backingstore has an HDC which the windows style uses for native theming.

Bo Thorsen says:

From TFA: “While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML.”

This is a HUGE change. And it’s one that has the potential to separate Qt from C++, at least to a certain extent. It should be much easier to implement other languages with this.

Bo.

Paul Miller says:

@sroedal – ah very nice!

Once this happens I’ll probably contribute a bunch of 16 bit per channel and floating support for QImages (I do almost everything in float these days).

sroedal says:

@Paul: Lighthouse and the minimal platform plugin will be available already in Qt 4.8 (but it won’t be the default, you need to configure with -qpa to enable lighthouse).

Philippe says:

The QWidget based programming model, despite some limitationsn, is a proven, easy-to-grasp and performant model, so please keep it alive in the *very* long term, even if you don’t make it central anymore. The rest, I don’t mind ;-)

Lars Knoll says:

@philippe: No worries, it’s not going away any time soon, but the focus will be moving over to QML. We have some interesting demos integrating desktop widgets/components into QML. Longer term that will hopefully give us the best of both worlds :)

Per Arneng says:

Sounds like a good plan. Like some of the above i would like to see C++11 (C++0x) support. Lambdas, range based for etc… C++11 does really make writing C++ code more pleasant. It makes you more productive and that is in line with your goal to make it faster to develop apps.

Joe Zydeco says:

Lars, congratulations on the roadmap. When you hit 5.0, please remember all the Qt/Embedded developers that used to give your platform some publicity (and royalties). We’ll all be adrift on 4.8 headed for other adventures….

Hi,

Since you are not using native widgets, do you still expose the correct accessibility interfaces and objects on the various platforms (MSAA/IAccessible and UIAutomation on Windows, Gail on Gtk, etc.)?

How do you envision traditional desktop applications being developed using Qt5/QML — or applications that have a predominantly traditional UI?

- Reece

Ian Monroe says:

I see that removing features from QtScript is on the agenda. I’m probably fine with that, QtScript has a lot of features.

So I’m wondering if the situation with QML having a separate plugin system from QtScript will be resolved though? It would be nice to be able to use QtScript to create APIs for QML.

Consider this a request for a blog entitled “QML & QtScript: Bitter Enemies Become Good Friends”. :)

Tsiolkovsky says:

What about replacing the existing non-standard translation system with normal gettext? That’s one thing I would really like to see in new Qt.

ary says:

“embed and power up web content and services into any Qt app”

Does this mean Qt will get native support for WSDL and SOAP?

“long term we also see QML as the future for user interfaces on the desktop. The solution here will most likely be QML-based component sets that integrate with the native styling APIs on the desktop platforms.”

Yes, integrating QtQuick with the host OS’s widget theming system is absolutely necessary if you want this vision to come true.

Every application implementing its own widget style for things like push buttons would be a major step backward, not a step forward.

“Qt will require OpenGL (ES) 2.0 to work”

This will be a tough break for some users, but I guess it was bound to happen sooner or later.

“Modular repository structure”

Why not also make the actual Qt library more modular (i.e. on the binary level)?

Greg Burri says:

Is qmake going to use the new JSON/Javascript syntax?

Lars Knoll says:

@joe: Qt/Lighthouse should be a good replacement for Qt/embedded.
@reece: Yes. we also have some work ongoing to support accessibility for QML. There are ways of doing this without having to use native widgets.
@ary: yes, we’ll need to integrate with the host OSs styling system for QML components. We’ve done some prototyping and believe this can be done very nicely.

Scorp1us says:

Qt5 = Open Source AIR.

I whole-heartedly endorse this approach. C++ backend, scripting in JS.

I still think we need a Browser Plugin for QML viewer, and now sooner than ever. We should be able to use it as a testing ground for Qt5 Apps. Things like accessibility native theme-ing (including desktop color schemes, etc) QML/Qt5 could be used by web and native client developers today if we had this. You could demo native apps in browsers.

Qt will need
- a better XML DOM engine (with create/update support)
- proper SOAP support.

Off to read the whitepaper…

Alan says:

Following Greg’s comment on QMake, I was actually thinking that it might be better to ditch QMake and go the CMake route… Views?

Alan says:

@Scorp1us: my personal issue with Air is that it feels and is VERY slow.

Dan says:

It’s great.
I love Qt Quick!

ary says:

“Qt 5 we plan to develop in the open, as an open source project from the very start. There will not be any differences between developers working on Qt from inside Nokia or contributors from the outside.”

How will this play together with the commercial Qt licenses Nokia is selling?

Frederik Gladhorn says:

@Reece actually accessibility is going to be improved compared to what we have in Qt 4.7 and before. We already have some changes in Qt 4.8 and much more to come. For QML the accessibility parts are still research, but we have some proof of concept implementation. It will be somewhat similar to what web accessibility provides (ARIA) in that you can assign roles to items. With Qt Components you will get it for free, just the way it should be. At the same time it will be a lot more flexible and easy for custom widgets you create in QML.

Stephen Chu says:

I am also very interested in how a traditional desktop widget UI can be developed in this new QML world. Can someone give an example how what the process will be like?

Blake says:

Needs more official bindings to other languages.

Guido Seifert says:

Really no slightly more accurate hint possible when 4.8 will be released? To tell you the truth, at the moment this is a far more interesting question for me. Especially I am interested in 4.8. on Symbian.

David says:

Guys does this means that QML will perform as good in desktop environmenet as id does now in mobile? Or it means that desktop development is no longer interesting to nokia? Sorry for dumb question, just I never tried QML

Khertan says:

Focusing on QML for all platforms is my biggest fear for Qt5 …

smoggy says:

As a part of open governance and moving away from the “Not Build Here” could you consider creating a CMake qt build please.

Iván Todorovich says:

How do you think heavy business applications would work with QML? Lots and lots of widgets, displaying large database tables. Would QML handle this without burning the cpu?

ary says:

@Scorp1us

“Qt will need
- a better XML DOM engine (with create/update support)”

I read somewhere that QtDom is deprecated and slated for removal in Qt 5, and personally I won’t miss it.
In my opinion, they should not stop there but take this chance to completely restructure and revamp Qt’s XML functionality.

QXmlStreamReader/Writer is definitely the way to go, but currently e.g. the (massive) functionality provided by the QtXmlPatterns module isn’t integrated with this at all, and most of it is buried in non-public classes anyways, only exposing a tiny subset of what it is capable of to the application programmer in the form of simplistic “give-me-a-file-name-and-I-do-everything-for-you” solutions – forcing developers of Qt applications which need to accomplish any kind of slighly more complex XML-related tasks to fall back on third-party XML libraries like libxml2, even though Qt internally has all the needed functionality already (which is kinda sad, not to say frustrating).

Guido Seifert says:

David,
I did only a few experiments and simple guis with QML. A few buttons, Sliders, some nice flipping and rotating effects. Tested on Windows, Mac, and Linux desktops. I have not seen any noticeable differences between the different platforms and think QML could easily replace most if not all of the standard Qt widgets.

Guido Seifert says:

> I read somewhere that QtDom is deprecated and slated
> for removal in Qt 5, and personally I won’t miss it.

*Yikes* Don’t like, don’t like at all. This would break quite a few of my programs. Never really fell in love with QXmlStreamReader/Writer or QtXmlPatterns. But I suppose some price has to be paid for 4.x -> 5.x. :-/

SpinyNorman says:

Sounds good to me, even though I’m a desktop/QWidgets developer. The only way to keep the code base alive is to refactor/redesign as the target moves, and if there’s a gradual loss of backwards compatibility, then so be it.

I do hope there’s no loss of *functionality* though as QWidgets are gradually deprecated or deemphasized in favor of QML. Hopefully there’ll always be a way to do low level GUI programming – basic drawing to images/windows.

Since you’re “moving forwards” with Qt’s APIs, then it’s be nice to see some of the past C++ API decisions revisited. It’s be good to see Qt more fully embrace STL and if possible use a native C++ signals & slots implementation rather than relying on the preprocessor. I agree with other posters that the ability to use c++0x lambdas for callbacks (i.e. use std::function for callback functions) would be awesome.

Ben

renato says:

Hi, any plans for make the current QMetaObject structc more dynamic. We are working on PySide and we will love have the possibility of create dynamic QSlots/QSignals. Because the current metaobject data does not allow insert new signals due the metadata order, signals came before slots then you need reserve some space to insert new signals. Will be nice have some way to handle this more dynamic and real (not like QML does).

Shmerl says:

Does open governance mean, that different Qt ports will be treated as first class citizens within the Qt project (like Android one and etc?).

HGH says:

Sounds great but is JavaScript that good to start relying on it so much for everything? After all it was invented for simple web scripts?

Lars Knoll says:

@SpinyNorman: Yes, there will be low level graphics functionality available to you. This is not going away. In fact, very little of the APIs you know from Qt4 are going away.
@Shmerl: Yes, it will only depend on the level of commitment of the people doing and maintaining that port.

gunnar says:

Guido Seifert: We are removing very little API. In fact, we aim to remove almost NO API. The DOM API will most likely see very little further development (which already has been the case for some time), but the code won’t go away.

ary says:

@HGH: I’m also a little reluctant about the “JavaScript for everything” approach. Sure, for little 5-line-snippets it’s perfect, but it’s really difficult to write large patches of object-oriented, easily-to-debug and easy-to-reuse code with it.

There are definitely some more modern scripting languages around.

Why not make the scripting support (in QtQuick etc.) plugin-based, so support for other languages could be added by external developers through open governance? Or would that approach be infeasible or considerably hurt performance?

uglycoyote says:

QML, javascript and OpenGL ES are great.
I think injecting c++0x into Qt voids older compilers/platform compatibility including WinCE and even S60.
But c++ signaling is a highly wanted.

my biggest wish is official port of Qt on Android and WP7 and more and more KDE collaboration.

MySchizoBuddy says:

Will there be improvement to mac widgets. right now they still look alien.

Cristian says:

I would like to see more C++0x usage in Qt 5. Today I was forced to split some code into multiple files because some weird moc limitation (more info about moc limitations here: http://doc.qt.nokia.com/latest/moc.html)

Eduardovich says:

@Tsiolkovsky: If you don’t like the translation system, don’t use it. It’s optional, you can use gettext within a Qt application just fine.

Aamer says:

WORRIES -
- “JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++.”
One of the greatest strength Qt had was it was C++ based. The OOPS design and use was straightforwrd ! I wonder how it will fare with JavaScript :-( Afraid if C++ developers would like JavaScript.

- ” Qt will require OpenGL (ES) 2.0 to work.”
Is Qt not being targeted to desktop versions ??

- “We should expect that over time all UIs will be written in QML”
How can QML provide full power of making custom UI’s ? Can we override paintEvent() ? Can UI’s like huge Table views with lots of data, something like Excel, ON DESKTOPS, be made in QML ?

LIKES -
- “Make better use of the GPU, allowing you to create smooth (and accelerated) graphics performance even with limited resources;”
Wish QtOpenCL also happens

- “Base all Qt ports on Lighthouse”
Want Qt Everywhere :-)

Steve says:

> Qt will require OpenGL (ES) 2.0 to work.

Do you mean exactly what you wrote, or will we still be able to use QCoreApplication (or equivalent) independently of any graphics subsystem?

While I’m here, are you going finally stop using a signed (!) integer for size_type in the container classes? Given that a block of memory can’t be smaller than zero, 31 usable bits is not enough; I’d like to see it set to the native size_t as some STL implementations do.

Steve

Konstantin Tokarev says:

@Tsiolkovsky: Qt’s translation system is much better than outdated gettext

sroedal says:

Aamer: We’re using the common subset of desktop OpenGL and OpenGL ES 2.0, which is sufficient for the kind of UIs we want to be able to create with QML on top of scene graph (which including smooth and sexy shader effects).

Steve: Qt Core will not depend on OpenGL.

Konstantin Tokarev says:

>Qt will require OpenGL (ES) 2.0 to work

What about embedded devices which don’t have OpenGL capabilities?

M. Pospiech says:

I use Qt only for science applications in the university. There we are happy with the ui approach and see no usage of QML whatsoever.
Especially because I do not even know a single person who can code javascript or is interested in fancy gui.
Qt lacks some important widgets, but most of them can be found as independent os-libraries.
If Qt skips the ui approach I wonder if we would still be using Qt…

JubiluM says:

@Alan:

“Following Greg’s comment on QMake, I was actually thinking that it might be better to ditch QMake and go the CMake route… Views?”

Well I’d say just quite the opposite, don’t even think about the CMake :D ! No, seriously it is a question of personal preference, they both are sophisticated tools and do basically the same thing. I just think that with QMake I get cleaner and much more easy to follow – (q)makefiles compared to CMake.

Stanislav Parkhomenko says:

I would like to know when the limitation “one class per dynamic library” will be broken? The desktop-orientation is cool and, may be, it is very useful for Nokia, but I don’t see any improvements in Qt’s core. The improvements of core — improvements for everyone (and Nokia too)!

About myself: I’m a student from Russia and I’m using Qt in academic research work. I’m trying to build a modular server (like Apache). I have started to work with Qt since version 4.2 or 4.3 under Linux. Also I’m a KDE user.

We are C++ programmers and so is the current Qt universe. What’s missing in Qt is server/Client P2P capabilities across the web.The largest brunt of Qt web code is focused on displaying/receiving from the web, not easily sending data over the web. That is not a limitation of C++ but of Qt. The Lighthouse project used with Google’s Native Client may be the way for Qt to find it’s greatest growth as it will allow P2P computing. You should be focusing on that. The entire world of computing is fading out of desktop computing to mobile clients that need to talk to one another. Being pretty is important though as we need to keep our customers interested . QML does have that potential. I just returned from the Embedded conference. It’s all about C or C++. If QML is made to handle fast, elaborate interactions with C++ over P2P clients and not just the trivial programs that currently grace the Internet then I would agree to leave the GUI system that made you popular behind. The future of all computing is based on large amounts of complex data intercommunicating across web clients. Meet that challenge and everyone in the world will come knocking at your door. You are still the best SDK out there.

codenode says:

Please don’t forget, that all those neat surfaces with QML need to be connected to the web, so better Protocolsupport would be nice. (SOAP, WSDL, JSON etc.)

Also C++0x features would be nice!

Sorry, please don't says:

Sorry, please don’t.

Leave JavaScript to the browsers. We are already SICK of that language.

Please keep Qt5 in C++ (or better, C++11) and, if you need a scripting language, choose Python 3.

I use Qt because it is the best framework for C++, period. I would *not* use it if I had to program in JavaScript. If so, I would just develop a web app. Which, in turn, I can’t, because if I’m using Qt is because it is more complex than a browser/JavaScript can handle efficiently (e.g. simulation, rendering, CAD, OpenGL, etc.).

Richard Moore says:

@Stanislav ‘I would like to know when the limitation “one class per dynamic library” will be broken?’

What limit are you referring to?

damian says:

Will the opengl es 2.0 requeriment mean that I won’t be able to run any qt 5 app in my netbook?
Is most the rendering made by cpu right now? if it is, would I be able to run qt 5 apps with something like llvm-pipe?

I’m a bit worried ,also, about the javascript thing, does this mean that people will have to learn 2 different languages to program a good qt app?, or is qml simple enough to understand without knowing a thing about javascript.

Apart from that, seems a very good direction for qt, I specially like the open governance, lighthouse, and web integration stuff.

Christoph Bartoschek says:

My biggest wish would be to get again useful X11 support over the network. Current Qt applications are very sluggish when they are started over the network, even over 1G ethernet. The worst example is KDE. It is unbearable to use on X11 thin clients.

Guido Seifert says:

damian, Sorry, please don’t,
see gunnar’s response to my post:
> We are removing very little API. In fact, we aim to remove almost NO API.

Looks for me that you CAM use javascript, but since all the old apis remain valid, you can code as usual. :-)

Will Stokes says:

Wow, this is downright scary. Will we be forced to:

1) abandon using QGridLayout and doing layout ourselves in code (aka C++)? For dynamic UI’s it’s often very nice to be able to
build a GUI and add widgets to a layout using a for loop. Is this even possible using QML?

2) I’m not a fan of having to use a mix of Javascript and C++ to write Qt apps. I enjoy using C++ and little CSS here and there just fine.

3) For complex custom widgets (of which I’ve created quite a few) I find it essential to be able to subclass QWidget and reimplement paintEvent, open a painter on this, and start drawing. Not all UI’s can be laid out ahead of time. Sometimes you have to deal with massive datasets and it’s easier/cheaper (aka less memory intensive) to handle things yourself and garbage collect portions of your very complex UI yourself and do all the painting yourself. It also makes it easier to implement thinks like copying rich graphics to the clipboard or implement printing.

Frankly, I really am not thrilled with graphics view (although I do use it in one location in my application) and I’m not terribly excited about being forced to move over to QML either. The only thing about QML that excites me is perhaps it does a better job hinting how things should be aligned with each other where as you have to play various tricks with QGridLayout to pull off the same effects.

I suppose if I were to make my own Qt5 wishlist it would begin something like this:
-finally make QSpinbox look native on a Mac OS X

-make widgets that require focus glows/margins placed in an internal layout (aka laid out in a QWidget container which in turn is laid out in another QWidget) not allocate the focus margin on the inner most container that is laid out.

-keep supporting QMake, which is really a great tool that works very well. By using both .pro and .pri files you can generate downright beautiful project files.

QuanTize says:

Confused…

Blog post starts out saying that the future market is towards mobile devices with touch interfaces and then turns around and says that only desktop systems (Linux, Mac, Windows) will be supported. Is this not saying outright that QT *plans* to become irrelevant?

Maybe I’m missing something here… :/

Scorp1us says:

@ary:
Qt needs a way to programatically create XML. I’ve used all the XML classes, and sometimes, there is no substitute for being able to navigate a DOM tree. How do you compare two XML documents? Without DOM, you can’t be cause attribute ordering is not defined, ergo any textual comparison will fail. Same for XML patterns, etc. DOM may be a pain, but it needs to stay. Otherwise every time you make a change, you have to completely regenerate the document.

@sorry please don’t:
What you are really asking for is an “Any”Script core where you can substitute any interpreted language – Java, Python, JS, PHP, etc. And I agree with you, you should be able to choose our scripting language. But JS is fine. The nice thing about JS is it is well understood by C/C++ heads and Web developers alike.

Neolander says:

“Qt will require OpenGL (ES) 2.0 to work” > Great… That and more javascript means I won’t be using Qt anymore. Gotta find something else… Again…

gunnar says:

damian: QML Scene Graph runs on top of the Mesa software rasterizer on systems without any acceleration. The performance is not great, but I seem to recall a mail in my inbox where somebody had already ran the QML Scene Graph on llvmpipe with quite good performance, but no personal experience.

damian says:

Thanks for the answer, I know that qwidget will still be there, but as qml seems to be becoming the prefered and optimal way of developing qt apps, then it should be supposed that If I develop a new app and don’t know qt I should use qml, that still means learning 2 languages to develop an app which needs a bit of performance critic stuff on it.
And what about netbooks?, will the new qt 5 qml apps work on them?

JSroad says:

The longterm goal of Qt is to transform it into a JavaScript library.
This way Nokia could sell Qt to Google.

damian says:

@gunnar: seen your answer just after I posted, thanks that answers the part of the netbook.

kevin says:

QML is unusably slow on PC/Mac if you dynamically build UI’s with more than a few dozen widgets. I dutifully tried adopting it only to find my programmatically created UI’s taking several seconds (!) to create, and being almost instantaneous using the old way. I can’t see it be appropriate for desktop apps. I’m worried QT is abandoning the desktop. Will Autodesk use Qt5 for Maya or are they branched and going their own direction?

JSroad says:

No MS needed to kill C++ Qt.

Most Qt coders don’t like gtk because it is plain C, do you think they will like JavaScript?
You could not ride the Smartphone wave, too late, iPhone and Anroid make the game.

Kuba says:

From my initial playing with Qt Quick it seems that there are some unwarranted fears expressed in the comments.

First of all, you can code any sort of a custom visual element in Qt Quick using C++ — that’s how all the basic elements are implemented, of course. Since they are QGraphicsItems, you have a paint() that you reimplement, etc. A QGraphicsItem is way more flexible than QWidget.

QWidget + QLayout system is pretty much technologically obsolete at this point. QLayout’s design is basically a hack that has been alive for too long. Layout has been cleanly implemented in Qt Quick and other modern frameworks like WPF. The abstractions used in QLayout simply don’t scale. If you have multiple items that you have to align on the screen, with QLayout you have to do it exactly like you’d align things in a spreadsheet: create extra columns and rows, and then “span” multiple ones here and there. They all have to be in a single layout, too. It’s cumbersome, and there’s no easy way around it. If you have items inside of a layout, there’s no way to align anything in enclosing layouts to those items: layouts are essentially an impermeable barrier that only exposes its own boundaries. Good riddance.

QWidgets are clipped to their outline and creating any sort of a visual effect that extends past a widget boundary requires horrible hacks and calls for poor code organization: enclosing widgets need to be aware of their childrens’ requirements. UGH. Again, good riddance.

The use of a scripting language, any scripting language, in Qt Quick is required, first of all, to implement sane bindings. With current C++ you’d be stuck with some template magic -or- writing custom functions for each and every binding. The way Qt Quick works now, AFAIK the code for the bindings is pretty much generated on the fly, and the JavaScript runtime takes care of hotspotting that code.

If you have properly designed QWidgets, it’d be almost a no-brainer to port them to become QDeclarativeItems. Also, existing model-view framework is exposed in Qt Quick. You can use QML components to display data from your existing QAbsatractListModel. The delegates are created on the fly, and also destroyed on the fly, and there isn’t anything in the architecture that would make it any worse than the C++-based model-view you may be used to. A model with thousands of rows works fine, you don’t get thousands of delegates created.

As far as I’m concerned, as long as QStyleItem (or something similar) will be rolled into Qt 5, your Quick UIs can be natively styled and the composition of native styling with your own design is much easier to achieve than in QWidget world, where you have to do it all by hand. Compositing QImages gets old real quick if all you want is to layer a couple of things on each other…

I’m also pretty sure that the requirement for OpenGL ES doesn’t apply to the Windows desktop platforms, and I doubt it would be required on X11 either. Qt has optimized CPU-based rendering fallbacks all over the place, and those won’t be going anywhere.

I don’t think that throwing hands up in the air and getting all alarmist is very productive…

gunnar says:

Kuba: Jens blogged about some initial desktop components a few weeks ago: http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/. As for requiring OpenGL (ES) 2.0, that requirement is for Windows and X11 alike, most of which have GL 2.0 support in hardware. For desktop platforms that don’t have GL support in hardware, there are other solutions. ANGLE for windows for instance, in addition to what has been discussed just above in this thread.

Kuba says:

@kevin: I’m sure they will be working on optimizing the heck out of it. They spend significant time optimizing “lesser” things out (say text codecs). How were you creating those UI elements programmatically, anyway? They are pretty much QGraphicsObjects, I can’t imagine them being extraordinarily hard to construct. I don’t know your exact circumstances, but from my experience if you programmatically create multiple widgets in a grid, you should be using a model-view instead. That’s what I found in my code that’s used in data acquisition to display devices, channels, etc. The view will construct your widgets for you, automagically, and I haven’t found it to be slow at all.

Kuba says:

Gunnar: I’m using those desktop components ;)

M. Pospiech says:

If Qt drops support for QWidget completely:
What will happen to all non-Nokia widgets that we rely on? For example qwt?
If we can not use it anymore, the same applies to Qt.
Will it be possible to design UI-Interfaces in a ‘designer’.
I prefer not use code for uis unless it is required.

@Kuba: From your text I have the impression that QML is all about visual effects and styles, which I do not care about.

Would it be possible to have a c++ backend for QML for those who do not care about style, effects and custom uis?

hate-engine says:

“even entire applications will be written in JavaScript instead of C++.”

Nice. Now hordes of code monkeys will create another millions of crappy programs, like they’ve already done with PyQt.

“Qt will require OpenGL (ES) 2.0 to work”

So it will be time to dump Qt out of embedded world.

Someone is very stupid if he thought he can transform UI designers into programmers.

Stephen Chu says:

So in the new QML world, what is the replacement to QGraphicsView? Specifically, I have some custom QGraphicsItem classes that handle giant image files. What will be the new, right, and shining way of replacing them?

Shmerl says:

Putting it to extreme does sound unreasonable. Better approach is – separation of design/UI part (QML) from functional part (C++). This works the best, IMO.

ddenis says:

Stephen Chu: QSGGraphicsItem which has an api very similar to QDeclarativeItem

Shmerl: surely you can do that. Qt5 will allow you to have “main” entry point in qml, but it doesn’t stop you from having c++-based plugins that are loaded at runtime to expose some application logic (via QObject properties and signals/slots) as a QML element / javascript object.

Will Stokes says:

Perhaps the reason this is all alarming is that last time I checked Nokia hasn’t shipped (with a Qt4.7.* release) a complete example desktop application based on QML that looks and behaves like a native application based on QWidget’s and QLayout’s for us all to learn the new way to do things from.

Lapol says:

It would be kind if you could be more explicit about the OpenGL requirements.
Does this mean, Qt will practically be unusable in remote sessions via RDP/VNC/X11 (without DRI) as there will be a slow software renderer bottleneck like MESA (or network translated OpenGL) or inefficient raw full-screen transfers for “every pixel” changed? And/Or is this setup is considered unsupported anyway?

What about the aforementioned business focused applications that rely heavily on tables and form based data masks? How well do they fit in an OpenGL based QML abstraction?

What about QGraphicsView, is this considered deprecated as QML (as the central technology element of Qt5) will be using QSceneGraph? Will QGV be some kind of a fascaded QSG in the future or what is its exact roadmap?

I appreciate your openness and hope to find a Qt5 that makes everybody happy.

Best regards.

ddenis says:

Lapol: hotestly, Qt apps are already mostly unusable using remote (RDP/X11) sessions – and nobody seem to care – I remember seeing bugreports about remote sessions not working properly for several releases in a row. If anybody cares – patches are welcomed.

QML apps is mostly about fancy UIs with fluid animations driving at 60fps which is hardly a necessity on a remote connection.
At the same time, QWidget-related classes are not going to go away, but being moved to a separate Qt module, and, again, patches to improve things are welcomed as part of the open-governance project (see separate blog posts about it)

ddenis says:

Lapol: I do not see why business focused apps cannot use QML. See QML Components for desktop project for example: http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/

@Will Stokes: This is the *future* development roadmap being discussed. Not what is here, and on your devices, right now and today. This might mean it sounds scary if you can’t imagine that the software you used today looked nothing like it does now, a few years ago.

As the technologies involved grow, and mature, and actually become capable, perhaps then you’ll have examples. But you have to have something to write examples for, first.

Fazer says:

So far my only propositions for Qt5 would be:
- allow signals and slots in templates
- allow multiple inheritance of QObjects
- QVariant should know if its stored type has some inheritance

I don’t know if they’re technically possible and how would they break compatibility, but having them would make coding much easier.

Kuba and all

I am happy to hear that the QML components will be efficient and all that exists in QT Designer forms will be able to be translated to QML fairly mechanically. I don’t know QML yet but it’s potential for screen animation is really nice and I do understand the problem with handling the screens with better code, I get that message. I have a couple hundred forms to convert eventually so that won’t be an easy task but if they look better and work better, it’s all upside. QT 3 to 4 was a real beast of a change. It will probably be the same from Qt 4 to 5. What I wonder about is why Javascript? Is it necessary? What I mean is, what is the upside to Javascript instead of C++? C++ can talk to the metal (CPUs, GPUs), directly without a layer to slow it down and it can be just as object oriented as you want it to be. There are problems with memory leakage but then it gives us the power and speed of pointers which are really efficient. I also get the OpenGL 2 jump. If we do GUI, it’ll be on the GPU, message received there also, the screens will look more 3d-ish, even on embedded devices. I can’t imagine any chip manufacturer not embedding 3d into their new chips. The jump from OpenGL classic to OpenGL 2 is not an easy one. I’ve used Qt3d and it’s not as flexible as I would like it to be but I’m sure they’ll iron those problems out as people want ways to manipulate meshes and it’s difficult to do so. Sorry about the removal of Qt from phones, I believe wholeheartedly that it is a mistake and because of this blunder, we are looking to see if Qt will deteriorate. MS does not want Qt as a competitor, that’s just the way they do business, I don’t blame them for that. All in all, we all hope the changes are for the best and since we are more involved in the code, we are more outspoken. Thank you for the work and I hope Qt has a brilliant future.

name it QML 5 says:

You’re “obsoleting” the best C++ GUI framework in favor of overhyped declarative JavaScript toy.

At least you should have gone with the proper scripting language like Python.

Lapol says:

ddenis, As for RDP, it’s a difference in coping with bugs or being conceptually orthogonal. Patches can only help that much in such a situation. Obviously QML is nothing at all for a remote session thus my little concern (or OpenGL in general FWIW).

Using the QML components for existing desktop applications does imply one critical thing: Rewrite of all the existing GUI code. So that’s hardly an option.

Also it’s the layout management for resizing windows etc. that is important in those common use-cases.

On top of that it’s more important to know that there will be no performance penalties when using the “legacy” QWidgets when they are indirected via a scene graph and OpenGL in general.

I am not convinced yet, that QML will be a better way to handle all this. While QML is VERY nice for touch friendly embedded devices the desktop prospect is not clear at all to me. While I see some particular use cases on the desktop too (like fancy media players or twitter clients or casual games) for others it does not seem that suitable at all.

And while I do not doubt that QWidgets will live for a long time, I still wonder if they will be treated as second or even third class citizens and what the performance and maintenance will be like.

Thanks for the reply.

Lapol,

If you aren’t happy with how something is maintained, then you have the ability to influence this. I imagine that widgets will most likely fall into a “Done” description (per http://labs.qt.nokia.com/2011/05/03/qt-modules-maturity-level/).

This would roughly mean – if it is the case – that the maintainers would agree to fix any critical bugs with it, but other than that, it wouldn’t be getting any major new work (other than the work stated in the whitepaper to bring them under scenegraph).

As to one of your other concerns – desktop use – QML is not just about animations. If you want to create boring, regular desktop applications, QML lets you do that too. The Qt Components project (http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/) will make this a lot simpler, and a lot more integrated.

max says:

Qt can development webserver. Qt have some component like windows’s WCF.

Tukla in Iowa says:

I remember when we COBOL programmers had to start learning Java. Crazy! Java was slow and chewed up so much memory and processing time. It was fine for little web applets, like it was designed for, but using it in a business application was a sure bet on failure. And don’t even get me started on those graphical interfaces! They were bloated and and complicated and didn’t add any value over our character-based screens. Our customers didn’t want to upgrade their hardware just for eye-candy, and anyway, I already knew COBOL!

Sorry for the trip down memory lane. I’m not sure what brought that on.

Benjamin Kay says:

C++11 (C++0x) offers many new features that could make applications written in Qt more elegant. If you’re going to break backwards compatibility, don’t waste the opportunity to incorporate C++11.

Aamer says:

@Pierre Chicoine Totally agree with your posts.
Qt is not just about making some fancy UI’s.

I love Qt because it is C++ and it gives you complete freedom to do what you want.
I wont jump to using JavaScript being a C++ developer and find this move very much like hitting your own leg with axe. The whole reason why Qt is so much popular today is because it is C++ and very easy to learn, and it is meant for developers & designers(QML) – NOT just designers.

With ONLY QML and JavaScript I guess Qt might become a kind of closed system where you dont have much power to do your own things ( refer desktop application having huge data , scientific applications , CAD applications ). QML is meant for small fancy applications on mobile and embedded systems.

— “For those of you that were with us for the transition of Qt 3 to Qt 4, we do not plan to repeat that difficult transition with Qt 5.”
Qt 3 to Qt 4 involved transition of classes. Qt 4 to Qt 5 will involve transition of language ( refer using QML and JavaScript from C++). Do you think it will be a smooth transition ? I wonder how many C++ developers would move to JavaScript !

ALARMING -
First, Qt was abandoned in smart phones by Nokia, and now with Qt 5 what do they plan to achieve ? For surely QML and JavaScript can be a cup of tea for mobile applications only.

The way I would have liked Qt to evolve is -
1) Use of GPU for coding ( Enter QtOpenCL ) . As days pass by there are large amounts of data to be shown visually appealing, and the importance of parallelization and computing power grows.

2) Better support for P2P applications as mentioned by Pierre Chicoine. Web was an area Qt havent been major player yet.

3) Better support for multiple platforms ( Lighthouse project ). And official port of Qt on Android, and if possible iPhone :-)

4) QML for mobile / embedded applications. ( But not to be the main component for developling)

5) More research on Audio/Visual/ Human Computer Interaction.
Future is not about mobile devices. You will have computers everywhere without keyboards and mouse ( something like MS Kinect ). Qt should have focussed on how to have interaction and support for such kind of future.

6) Development of Qt based libraries / modules for general purpose communication. Say like having video streaming library, or library for Bluetooth / WLAN , Audio/Video processing. Idea is to make small modules/libraries which commercial applications can make use of and hence have Qt everywhere.

7) WOW effects on both desktop and mobiles .

Aamer says:

Also one should consider the use of Qt in todays industry( kind of applications ), and whether or not they will like to move to QML in future. Can those application be re-written in QML ??

Aamer says:

By the way, this post gives me more shivers and worries (bec am hard code Qt/C++ fan and developer) than the post in which it was announced that Nokia will not be using Qt in high end smartphones !!

hate-engine says:

@Tukla in Iowa: java is still slow and is still wasting too much ram.

damian says:

The qml and javascript move is a bit risky, you are making every c++ desktop developer do 1 of 2:
1) Learn javascript
2) Design whole gui in designer
There are a lot of people who like to do simple c++ guis, and don’t want to mess with javascript, what about giving a c++ module that translates into qml calls, something like qwidget that uses qml as backend, so the object button in c++ correspond to a button object in qml.
I’ve also heard that it isn’t good for making lots of little and static components(I imgine a word processor) will this still be true in qt5? or you will make the necessary changes to make qml a replace for everything.
PD:My technical knowledge about qt is not big at all, sorry If I’m wrong.

Cell says:

QML is just a new choice. You have right to use it or not. If you don’t like QML or javascript, you can still use C++ in traditional way with Qt.
And you can still take benefits of GPU accerleration or other optimaziations of Qt5.
In my opinion, C++ is not ever suitable for rapid development of mordern UI nowadays.

Jeisson Hidalgo-Céspedes says:

If Qt 5 development model is going to be in the open, it would be valuable to have a shared tool for selecting the best ideas, in the same fashion Ubuntu Brainstorm does [http://brainstorm.ubuntu.com]. Note, this blog post is becoming a wall of important ideas but they are unorganized. An open tool could help to manage ideas quantitatively, avoiding duplication, letting interested people discuss and improve their favorite ideas or needs. If everybody can vote and development is targeted considering those results, Qt becomes a proud democratic library.

XX says:

>’We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and >even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only >implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application >functionality.’

I think it will be wiser to expect both C++ and QML are the main languages in Qt.
QML cannot replace C++ even in UI design.
QML is easier to use, but C++ is much more powerful and creative, and I think most C++ developers don’t like to learn one more new language for UI design.
Your expectation makes C++ programmers feel disappointed and hesitated at the start of their Qt career.

Birdy says:

To all the javascript sceptics:
a) C++ developers should be able to learn javascript (the parts needed for QML) within minutes

b) QML is more like a highly flexible replacement for .ui files (that’s the way I’ll use it). All the program logic should stay in C++. QML can directly reuse exitsting Qt models for example. That’s the power of QML. It’s so easy to combine Qt C++ with Qt QML. And this way it’s absolutely natural to _really_ split UI and logic of an application. Something that is mixed up in nearly every application I saw. And always turned out to be a problem.
I personally expect that 20% QML and 80% C++ will be the case for average desktop applications.
Apps for mobiles might end up with 50% / 50% on average.

c) Python, as much as I like ist, is _way_ to heavy for the simple tasks needed for QML

qtnext says:

1)- Qml for now lacks several features : TreeView, Table … I have written application in QML where I need to use treeview : it’s just a nightmare …. fews days only to handle that … Ui is fancy but at an expensive price of times ….

2)- Model in QML : it seems QABstractItemModel and ListModel (qml), XmlModel are not compatible : I mean for example if I wants to add a new QML item like myCoverFlowPath : I mean write from scratch an element like a listview or a gridview, PathView … There is no intermediate declarative item to help that … we need to be able to add custom declarative item that can handle model

3)- We need some real life example of application written in QML + C++ … Some help to port application from pure C++ to QML C++

4)- Android is named in the whitepaper : good :)

damian says:

@XX:”Your expectation makes C++ programmers feel disappointed and hesitated at the start of their Qt career.”
I thinked the same, but if qml is simple enough to learn, it will probably be the same to learn qml, than to learn c++ way of doing guis, as for making c++ guis you still need to make stuff like ui files, and set properties, the only difference will be a bit of syntax.

Yet you should explain better that learning qml doesn’t mean learning the whole javascript, you just need to know the syntax and the properties/objects of qml, which you still have to learn in the old model (I mean learning the qwidget object/properties).
Also, it seems as if the main focus being qml, the old qwidget will enter in semi-deprecated mode, where no real innovation happens, if you do this, in the longterm qml will have to replace qwidget in every situation, So as I understand it qwidget will be mantained and semi developed (I guess the community willdefine how much) while qml gets ready to rock right?, I ask because I don’t think it’s totally clear.

m128i says:

Sounds good to me. Especially if QML works seamlessly with a QGraphicsView equivalent, this could make a lot of things much easier. Right now, using QGraphicsView is cumbersome as you have to layout your items manually, which QML would solve easily (using QGraphicsProxyWidget is not really an option.) The other great thing about QML is that styling your application becomes easier, something which is getting more and more important.

What kind of transition plan do you have in mind? I’d be happy to see a Qt 4.8 or so with lots of QML improvements so I can start porting my application UI over to QML/write new applications on top of QML and then benefit from the tighter integration/faster performance in Qt 5. Plus some documentation about the parts that will likely require some porting later on.

BTW: Is there any chance to get Python (3?) bindings to QML running side-by-side with the Javascript backend? I use PySide/PyQt/PythonQt occasionally, and being able to write everything in Python there would be cool.

Mike says:

I am really afraid of the OpenGl depency.
How to deploy a complex desktop application then? I suddenly would have to deal with thousands of opengl configurations out there. This is a real QA nightmare.
Also if everything is opengl how do I embedd native widgets/active x controls?
How do I embedd another OpenGl window or even a directX window?
These are real and important usecases.
Please keep a rasterengine fallback/backend for the people that do not want or cannot rely on OpenGl.
Remember that not everyone needs fluid uis and opengl. But I also do not want to fork Qt 4.x.
You call QWidgets finished, but they are not. They still need bugfixing (mac os x!) and also they could be improved alot. Also please make sure that the main application can be pure c++ that drives a couple of qml files as different forms.

Maverik says:

For me it comes down to one question:
Will Qt Creator be ported to Qt5?

This would really gurantee that Qt5 is suitable for serious desktop applications and not just “apps”.

Hermit says:

Why QML can’t (optionally) use C++ instead of JS? For external files that may be impossible, but if you want only your code with no outside QMLs read from disk… why not?

Guido Seifert says:

Hermit,

> but if you want only your code with no outside QMLs read from disk… why not?

You don’t need to read QMLs from disk. QML can be integrated in the binary as any other resource can.

Erik Verbruggen says:

@maverik: Yes, we will port Qt Creator to Qt5. And you are correct: we will need QWidget & friends for that. But this will (probably) not happen over-night.

@Hermit: QML is an extension to JS. Take the core (JS) away from an extension (QML), leaves you with…?

@I-don’t-like-JavaScript-posters: I am quite sure that Lars’ post nor the whitepaper says anything about QWidgets going away, so worries about that are a bit over the top. What he does is identifying a trend (QML), and describing how that can be made into a first-class citizen, just like QWidgets are a first-class citizen.

friesoft says:

You just pointed out that you will (obviously) port QtCreator to Qt5 but you also stated that it will need QWidgets – should this be the long term solution? Why not use the Qml based pendants instead or do you think they won’t be suited for QtCreator? and if so: why?

According to your statement it sounds like the following:
Qml for bling bling stuff and tiny desktop applications
QWidget for all big desktop applications which would perform horribly with so many Qml Items

Did I misinterpret something wrong or is it just that too much porting work would be required to do it all at once and you therefore said that QtCreator will need QWidget?

Nonetheless the future of Qt sounds really cool :) keep up the good work

If QWidgets+QLayouts on top of QML is to work, then:

1. QML needs to support *all* the functionality (menus, trees, tree-lists, file selection dialog, …).

2. QML layout and rendering needs to perform at least as good as QWidgets for complex layouts.

3. There needs to be support for building up the UIs in C++ (as can be done with QWidgets) as well as the QML files binding to C++ and QML files binding to JavaScript.

4. Derived classes need to be supported for creating custom/extended UI (e.g. KDE) and for common event handling or using data that isn’t exposed through QObjects and properties.

André Lochotzke says:

A few people have already voiced their concern with Qt5 requiring OpenGL (ES) 2.0. The proposed solutions for desktop applications are simple enough, but what about embedded ones?

Qt4 works nicely on systems with resource restrictions (ARM with 600MHz, no graphics acceleration) by using the framebuffer. If you add MESA to that for Qt5 you end up lacking performance that you need for the actual application.

Would I have to stick to Qt4 with a simple system like this?

By 2012 SoCs that you connect a display to will most likely have OpenGL (ES) 2.0. So I guess it won’t be that big of a deal.

Joachim Puhr says:

My opinion: Think about your proposed way again. I’m afraid many developers (like me) will leave Qt.

Why? Because Qt is an outstanding C++ framework; not in the first place a Javascript or a whatever-proprietary-API framework. That is the reason why I (and my colleagues) use it.
The mix of C++, QML and Javascript does not (!) reduce programming complexity; it increases it a lot, because every programmer has to be familiar with three (including CSS: four!) different programming languages and paradigmas; each needing deep knowledge if you want to use it professionally.

Of course it is always desirable to evolve; but I think you are evolving in the wrong direction, because it seems you want to evolve away from C++, your draft horse. But C++ itself is evolving. Think of shared pointer: I wished you would shift to shared pointers competely (No more use of any plain old pointers in any Qt function). OpenSceneGraph is a prime example in doing that.

J. Puhr, THALES Deutschland

jrubr says:

Will Qt 5 support Nokia Windows Phones? Will be nice to add some platforms to the cross-platform statement.

Jérémie Delaitre says:

@Joachim Puhr: An application is already a mix of paradigms but with a standard Qt/C++ approach, you’re often stuck with a single language (so called multi-paradigms language…) to develop your whole application. With Qt5, you’ll get multiple languages to develop the different parts of your application, each part with its own “specialized” one. Frankly, writing a GUI in pure C++/Qt is really a pain while QML offers a specialized language designed for this use case. In a Qt5 app, you’ll probably write the core of your app in pure C++/Qt as usual (using all QtCore, QtNetwork… features), the UI in QML (with its declarative + bindings approach which is really adapted to UI, and the “under the hood” scene graph which is really the only way to do proper graphics stuff), and the glue code in Javascript (which offers flexibility without the burden of C++).

lapol says:

@Robin Burchell: I think you did not understand my concern (it might be superfluous but not as far I see it now).
My concern is that Widgets will be always haven an indirection via QML and thus might be 1) less performant 2) less consistent 3) less controllable when using currently implemented event handlers.
Other than that I see a problem when using a remote session as it will be nearly “impossible” to for example have terminal server serving multiple Qt business applications in parallel with all the OpenGL emulation going on. That is something CONCEPTUALLY different and can not be handled via a simple community contribution.

I have seen the work of Jens and for one implies a rewrite of existing Qt4 code to use QML is just not a feasible option (especially given there seems not much to gain when porting plain old dialogs to QML). Other than that I wonder how efficient (and backward compatible) the layout management will be and how efficient will be a sophisticated table etc. etc.

Those are just concerns and nothing impossible to solve but it somehow seems the focus has shifted far, far away from industrial/business application in the roadmap.

Tobias Hunger says:

friesoft: Qt Creator is currently mostly using QWidgets for its UI. We will follow Qt5 development closely going forward: We want to have great support for QML, so we need to follow Qt5 for that and we are looking forward to some of the proposed API updates, too. So yes, Qt Creator will be ported to Qt5. We will (and actually already do) use QML, too, where that makes sense. It is not either QML or QWidgets, both approaches can be combined.

The decision to use QML or not is not based on the assumption that QML is “too slow for the desktop” (as you claim), but on whether the cost of redoing a UI is out-weighted by the benefits of doing so. QML opens up many interesting options for UI design to us and we are looking forward to investigate those, but obviously some dialogs will benefit from QML more than others and that is where we will start.

We do not see any reason to kick out QWidgets, just because we are moving to Qt5, so they will stick around in Qt Creator for what I expect to be a long time. QWidgets or QML is not the all-or-nothing thing many people here seem to assume.

PS: Please do not expect Qt Creator to turn into a Javascript application either:-) Again: We will use Javascript in UIs where the additional flexibility makes sense, but in general the speed and convenience of C++ is what we need.

Per says:

Ah, so much interesting stuff to digest. Generally, I love it. More OpenGL love, and V8 – awesome. I do not understand the fear mongering going around. QWidgets and C++ is not going away in Qt5, they will remain first class passengers. In fact, I doubt that anyone think people will write larger apps just in javascript. The trolls apparently think that in time we will all want to use Qt Quick for UI instead of QWidget, but if they are wrong about that, then surely any reasonable steward of Qt will adapt the toolkit to customer demand, rather than attempt the other way around.

As for what I would like to see in Qt5:
– support for safely aligned vector types in moc (for SSE optimizations, see http://eigen.tuxfamily.org/dox/TopicStructHavingEigenMembers.html for more info about issues with that)
– add some more serious math support for visualization by integrating the Eigen math library instead of the totally unoptimized, home-baked vector classes currently in Qt; with the above aligned vector support Qt will become a very nice platform for fast math, as it would solve vector type alignment issues that make C++ and vector types unsafe bed fellows. If the license is an issue – talk to the developers of Eigen, they seem willing to adapt it if required for greater adoption (see discussions wrt to its possible use in VTK and ITK)
– please switch to gettext. I do not care that Qt’s translation system is slightly ‘better’ — it is totally non-standard, and hard to push on translation teams used to gettext; sometimes ‘good enough’ is just that
– the tree and table widgets need more love; although not used much on mobile GUIs (yet!), they are widely used in Qt desktop apps everywhere, and doing more advanced things with them, like drop down menus, icons, drag and drop, etc, is pretty clunky
– use some of the new C++0x varargs stuff to implement a qWarning and friends that can take QString and friends as % parameters directly without all the .toUtf8().constData() verbiage — this is the first thing that amkes developers new to Qt cringe, and it would be nice to see it fixed (no, the .arg().arg().arg() stuff is not pretty, either, and do not suggest that people use the translation breaking << kludge)
– easier ways to use Qt with other languages, esp Go ;-)

Konstantin Tokarev says:

@Erik:

>What he does is identifying a trend (QML), and describing how that can be made into a first-class citizen, just like QWidgets are a first-class citizen

So you don’t intend to make widgets second-class citizen? Phrase “Classic QWidget based applications will get integrated on top of the QML optimized stack” worries me.

lamefun says:

Will there be a framework for creating styles for platforms that don’t have their own style, like QStyle now? Also, will it work for both QWidgets and standard QML components?

Justin says:

@lapol: My understanding is that the QWidgets are not being reimplemented in QML, they are still C++. All that is changing is that they will use the same drawing backend as QML – the scene graph.

lapol says:

Justin, for now there seem to be two approaches – first the work of Jens having native looking QML elements (i.e. a “rewrite” of QWidgets in QML) and second the existing QWidgets that will be get an extra indirection by letting QML/QSceneGraph do the actual painting of the widgets (AFAIU).
The second case is what worries me as it might be a performance problem especially on remote systems, while the first case let’s me wonder how tables and treeviews will behave and perform.

gunnar says:

lapol / Justin / Konstantin: So let me clarify the Widgets through OpenGL / QML Scene Graph approach.

We typically render the widgets using the raster engine into the QWidgetBackingStore / QRasterWindowSurface. This happens by QWidget recursively sending paint events into all the widgets in the hierarchy. The details are here: http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/ . This part is not going to change at all. We will still send the events to widgets and they will be rendered using QPainter into the same good old back buffer. What we are contemplating is change how we flush the backbuffer to the frontbuffer. Take Mac OS X as an example. Today we present the backbuffer by mapping the window surface’s bits into a CGImage and draw that to screen using CoreGraphics. The path through CGImage/CoreGraphics is a major bottleneck in raster based graphics on Mac OS X. We know we can speed this up significantly by using OpenGL and some Apple specific extensions for uploading the back buffer as a texture. So overall performance should not be expected to drop. In fact quite the opposite.

wicharek says:

Really, guys, moving to javascript is an awful idea. What’s the point actually? Make Qt comfortable to web-developers (or actually those of them who, I assume, don’t want or are not able to study C++). Really? Maybe let’s screw all the widgets/graphics scene stuff and just use Webkit? So webdevs just need to use the stuff they are familiar with: html+css+js.

My opinion:
1. Using C++ as the only development language should always be supported. Using additional scripting stuff should be optional.
2. Javascript as a language is ok, while it is optional and not the center of the whole framework. If it is, then why actually JS? There are much better alternatives (Python, Ruby).

Konstantin Tokarev says:

@gunnar: Currently in 4.x we have a possibility to choose “graphicssystem” of Qt, OpenGL being one of possible alternatives. Will it be possible in Qt 5 to select non-GL implementation? We are targeting low end embedded devices without OpenGL support

lapol says:

@gunnar: That might be true for OSX, but is it true for Windows with low performance on-board cards with broken OpenGL drivers? And as I said, it’s the remote sessions I am worried about as there OpenGL compositing will most definitely be much slower due to an OpenGL software emulation layer processing all the data.

Also I still don’t understand what the roadmap for QGraphicsView is, as it seems to be considered a QWidget “legacy” UI-element?! Will it still be officially maintained and improved? How does drawing work here? For example how will drawing in the case of an OpenGL QGV be handled?

Konstantin Tokarev says:

>That might be true for OSX, but is it true for Windows with low performance on-board cards with broken OpenGL drivers?

The same thing is more actual on Linux desktop where quality of OpenGL drivers differs significantly between graphics cards vendors

Bnilsen says:

@wicharek

Point is that the business logic can still be developed using Qt/C++ with QML UI on top. QML and Qt/C++ mixes very well together, and that’s the whole point. We combine the best from two worlds. Writing an UI with QML is way more powerful than widgets. Some keywords: Easier, funnier, better performance. Code Less. Create More. Keep in mind that QML is developed by developers, for developers AND designers.

Romain says:

I, for one, am very excited about this roadmap, and I don’t share the FUD spread in many of the misinformed comments posted above.

I can totally see this as a way forward for Qt, so it can stay relevant in 10 years from now, including on the desktop. Yes, Qt4 is great in many ways, but I increasingly see its limitations and shortcomings.

What I find surprising is the suddenness of this announcement and the scheduling. Having such a massive change happening in less than a year is pretty daring and disrupting. I guess there are lessons learned from the past years in there, but still, I’m not sure rushing it is a good idea, at least not as long as people have clear answers about Qt4.

And that’s the other thing that I’m missing in all this : any mention of the lifetime of Qt4 from now on, how long Qt4 and Qt5 will coexist, etc. I guess this is just a different subject that will require a different communication.

Personally, I would like to see Qt4 (ie Raster based, C++ widgets architecture) remaining as the standard platform for desktops and legacy hardware for a while (possibly a very long time, much longer than with Qt3 for instance), while Qt5 (ie OpenGL based, QML architecture) would be the new kid on the block, targetting new platforms and UI paradigms. Yes, this almost sounds like a fork, and the idea doesn’t sound all that bad to me actually.

Anyway, change is good, and I trust the people behind it. Heck, I still remember the days we were bashing on Qt4 while holding on to Qt3 :)

Bnilsen says:

@Romain

Regarding the announcement. We didn’t start to work on Qt5 *after* the announcement. This is something we have prepared for for quite some time, and making it happen within a year is not at all optimistic given the vast amount of eager developers out there willing to help out. We can do it :-) The software industry changes rapidly, and lots of things can — and will — happen within a year.

Markus Goetz says:

I wonder why people are implying here a move to Javascript.
It gets better support, that’s all :)
Qt remains a toolkit in and for C++ even with better Javascript support.

MNaydenov says:

-1 for the javascript + QML being the center of “the new Qt”. C++, is Qt’s main strength.

And to all “C++ is not going away, JS is just another tool”, don’t be fooled!
Its much harder-to-impossible to support two APIs to full extend (JS/QML and C++) then one, and this has an effect even now – many(all) of the QML Items and layouts are *not* available from C++!

What will happen, projecting the current status – there will be nice QML framework (even for desktop), written ontop on *private* C++ APIs.
There will be some basic tools (hopefully not as basic as DeclarativeItem) to use form C++, but you will have to reinvent a ton of wheels.
And even if you have higher-level building blocks, you still pay the prise of complexity implementing an decl item vs, lets say, a regular QWidget or a QGraphicsItem. This is because of the decl part, which often is simply not needed.
Thats the state of affairs at least for now.

I personally *pray* there will be an option to make pure-c++ app, without QML and JS (hopefully without QState-for-every-click)
AND have *all* the features of the platform available
AND still have the simple (and famous) C++ API.
Failing to do so will be a major C++ departure and a huge disappointment to all that use Qt right now.

Guido Seifert says:

> I wonder why people are implying here a move to Javascript.

This is the biggest horror of all C++ developers. Ok, the second biggest horror… but when they say Qt 5 will be based on .Net nobody would believe it. ;-)

Bnilsen says:

@MNaydenov

C++ will continue to be one of Qt’s main strengths, and unless you develop something that is visible on the screen, you can continue to use Qt/C++ as before. Nothing will change in that respect. The main use case of QML is fluid UIs and that’s where the biggest change is. We want to use QML for the UI part, everything else can stay C++.

Rob says:

As a massive fan of Qt and someone who has bought it into a large organisation I am completely underwhelmed by the thought of QML and JS. This is a show-stopper for me – I can’t be the only one who isn’t interested in using QML for developing desktop apps? Not everyone is developing mobile or web-apps,

Please think long and hard about this before you go an alienate a whole bunch of developers. Developing desktop apps with Qt is a breeze at the moment – if you complicate this then you will regret it IMHO.

Carl Sanford says:

As someone who hasn’t needed to write cross-platform desktop code in several years, I can say that there’s very little keeping me with Qt at this point other than the C++ development experience. A big push to JavaScript and QML will simply send me to WPF for new projects, as there are a lot more resources available for “real” applications in XAML than for QML.

Bnilsen says:

@Rob

Developing applications using Qt is a breeze, I agree. We do, however, see room for improvements on the UI side when it comes to performance, ease of use, rapid prototyping, working with designers etc. QML is our solution to the problem. I fully understand your concerns and thoughts, but please trust us when we say QML is a big step in the right direction. It would be a disaster for ourselves to complicate the development cycle. I strongly believe you may change your thoughts and concerns once you get more familiar with QML (which you would pick up on very fast). Been there done that.

sroedal says:

The ones complaining about Javascript might want to read http://www.crockford.com/javascript/javascript.html, explaining why Javascript has gotten a (mostly undeserved) bad reputation in some circles. It’s really a very flexible and powerful language. Note that you don’t necessarily need that much Javascript to make a QML based UI.

Also, have a look at http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ which shows how to use QML to make desktop UIs much more easily than with traditional QWidgets. Note that the demo is still running on QML on top of QGraphicsView, so you can expect quite a bit better performance in Qt 5 with the new scene graph.

Give QML a try before you denounce it.

lapol says:

@Bnilsen, I think the most important questions are:
“What kind of application do you develop?” and
“What is your target audience?”

I suppose answering those will show your affection towards QML and if you actually consider QML (and QML/QSceneGraph as the base for EVERY UI-element) a step in the right direction or not.

Rob says:

@Bnilsen

Not everyone uses UI designers, especially for desktop apps that make use of useful Qt widgets like table views, tree views, etc. I fail to see how QML is going to make my applications easier to develop, and yes I have already experimented with the technology. A whizz-bang UI is simply not required for my target audience and the fact that you mention designers is only going to scare people that a) don’t have any and b) can’t afford to employ one when they need to design a UI.

Stephen Chu says:

I don’t believe the claim that QWidget/C++ and QML/JS will coexist. At least, not for long. There’s only so much limited resource. There’s no way QWidget continues getting deserved development effort when the brave new world of QML needs more care to bring online.

I, and I believe many others here, experienced the same exact thing. Apple introduced Cocoa and claimed it will coexist with Carbon and both were to be the 1st class citizen in OS X world. 3 years later, Carbon was in maintenance mode, with almost all APIs deprecated with no replacement. And I don’t believe Qt/Troll has the same money and resource as Apple.

And a serious technical question: What functions or effects that QML/JS provides can not be achieved in C++? I know QWidget and QLayout have their limits and baggage. But since we are talking about creating brand new things here, what advantage do a interpretive scripting language has over C++, especially with all the new features in C++0x? Other than it’s easier to the web scripting kiddies, I really can not think of one.

TemporalBeing says:

Please integrate some of the Qt Components – such as QtService – into the main repositories and/or provide suitable replacements in the main repositories. For example, QtService is only listed as supporting Qt 4.4/4.5, and has been quite neglected; it does still work with 4.6 (haven’t tried 4.7 though I expect it works there too) but it could really use some updating and enhancements.

Bnilsen says:

@Rob

Not using UI designers is perfectly fine. The reason I mentioned designers is that some of us suck more than others when it comes to beauty UIs. In your case, you don’t collaborate with any designers and write the UI yourself, and that’s perfectly fine. You don’t have to be a designer to write QML code (being a C++ programmer is in fact a huge bonus as learning new languages is simply a matter of changing some syntactic sugar).


import QtQuick 2.0
import MyPlugins 1.0

ListView {
    id: listView

    width: 1280
    height: 1024

    model: MyCPlusPlusModel {} // Inherits QAbstractListModel

    delegate: Rectangle { // Defines how each item in the model is drawn
        width: listView.width
        height: 200

        color: "red"

        Text {
            anchors.centerIn: parent
            text: itemText // Declared and exposed in MyCPlusPlusModel
            font.pointSize: 24
        }
    }
}

That’s it for a complete and simple Item View / QListView application (given that you already have a C++ model).

More QML elements here.

xylophone says:

I wuld like to see that Qt5 to develop OPENCL

Konstantin Tokarev says:

It would be great if QML could be converted to C++ code like UI files to avoid run time interpretation.

Marius Cirsta says:

“Will it be possible in Qt 5 to select non-GL implementation? We are targeting low end embedded devices without OpenGL support”

I think this is a very valid question to ask. I’m not against making Qt better on high end hardware but there are still quite a few devices which don’t have a GPU or there aren’t any good drivers.
Qt 5 should have a fallback for when there isn’t any OpenGL and it should work on all platforms not specific stuff for Windows or Linux.

Konstantin Tokarev says:

>Qt 5 should have a fallback for when there isn’t any OpenGL

@Marius: Thanks for supporting my point, but only presence fallback (e.g. to software Mesa renderer) is not enough in our case. We need Qt 5 to perform not worse that Qt 4 does on such hardware, or we’ll stick to Qt 4.

foobeer says:

Great work… and finally. I don’t know why people hate so much things that includes word ‘java’ but does not have anything to do with java. I am sure that nobody is not forcing to use javascript, from my point of view the choice of language for Qt is C++ and will be so for serious development. Javascript gives easy way to prototype stuff without extra compiling and numerous c++ classes, in most cases it is fast enough*. QML is also a step forward compared to qpainter. QPainter is nice, you can easily draw circles and boxes like in basic school many ears ago. It’s not really a tool for modern times when drawing is done in multicore cpu/gpus even on mobile.
* http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=v8

Robert says:

Ouch

After 10 years of hacking (yes, hacking) UIs in Visual Basic, I was finally able to move to a real language, C++ with Qt
Am I supposed to do my highly complex, and sometimes performance-critical UIs all in QML, or else stick with C++, but get no new features out of Qt any more, ever?
Am I going to see shiny, cool components in Qt Quick, but only be able to use them in C++ via cumbersome proxy constructs (as is currently the case with the QML listview, which I would LOVE to have as a QGraphicsItem or QGraphicsWidget)?

I can see the charm of QML for an app that you would write in a few weeks, sell a few thousand times on the web, and then move on. I can even see the charm for desktop apps with relatively simple UI.

I don’t see it for a complex technical application.

J. Puhr says:

after talking with collegues about your plans the response was mostly “oh no”. One reason is: The core competence of our applications is the application logic, the internal algorithms, NOT the overwhelming eye candy. Exploding push buttons or rotating combo boxes are neither needed nor even desired by our customers (I am very sure of that). In the first moment those things are funny, but very soon it is bugging.
Instead I would wish a graphical editor to model the classes I am building (possibly with round trip engineering like the C# UML class diagramm editor in Visual Studio, that is really awesome). _This_ would really boost up productivity!
I would also wish: Consistent and overall use of smart pointers, as mentioned before. Better interaction of QObject to some familiar C++ concepts like templates and multiple inheritance. A possibility to make remote procedure calls.

Shmerl says:

@Birdy: That sounds good. Similar to how Mozilla handles XUL (C++ with JavaScript).

The main benefit of C++ – it’s not a VM. It’s native code where one can do such things as custom memory management, which is completely beyond the scope of scripting languages. I.e. making functional logic in C++ gives one all the tools for managing efficiency. And QML should stay for design and UI declaration. Shifting the whole thing into QML doesn’t sound good.

lapol says:

@Bnilsen, I suppose no one doubts that this trivial example works fine in QML.

Yet we have to see how a complex table with custom delegates based on different content types (i.e. using comboboxes, spinboxes,… with different sizes) that shows huge amount of data works (with a native look and feel), or how well the layout management works for a resizeable window or how easy it will be to implement drag-able UI elements that will get reparented into a different context, etc..

Those are typical business application use cases – which as of now are not really covered by QML as far as I see (for now at least). That type of application does not need any animated “bling” or “flick-ability” of listviews.

Please do not understand me wrong, I think QML is a great development for it’s particular use cases but I am still not convinced that it is a general solution to the UI-problem.

Same goes for my concern of remote sessions and the future of QGV (which I hope to get an answer to at some later point).

Tobias Hunger says:

J. Puhr: Your core competence is in the business logic? Great! That should have no problems with the transition to Qt5 according to the plans Lars announced. Stick with QWidgets for your UI if you prefer or go and explore what you can do with QML. It does not really matter: Both should work for you.

Even when using QML: Nobody is forcing you to have exploding buttons! Feel free to do that if it makes sense in your application, stick with something more traditional (using QML or QWidgets) if that is better for your application. QML gives you more options… whether or not you use them is up to you and your application.

A UML class editor is part of the tooling and thus out of scope for this announcement. It sounds like something nice to have, agreed, but is really hard to do (right).

Shmerl: No, not like XUL. Give QML a try, it is way more dynamic and powerful.

lapol: What makes you think business applications need to be boring? QML opens up new options for UIs, feel free to explore them or just stick with what you have, just like we do with Qt Creator.

jut says:

Need a Grid handle big amount of data. Like “lapol” mentioned.
With more features, easier handling of Widget’s in it without need of delegate anything.
Grouping of items, filters aso.
Like XCeed for .net does or more.

ary says:

@Stephen Chu May
“I don’t believe the claim that QWidget/C++ and QML/JS will coexist. At least, not for long. There’s only so much limited resource. There’s no way QWidget continues getting deserved development effort when the brave new world of QML needs more care to bring online.”

Maybe you should read up on how the whole Open Governance thing will work before you start spreading such FUD.

As long as there are developers out there to whom the QWidget functionality is important (meaning: for a looooooog time), it will not disappear or become unmaintained, even if some day (in the distant future) the maintainer won’t be a Nokia employee anymore, but rather an external Open Governance contributor (which won’t make much of a difference at all).

Also, you’re wrong in associating Qt’s C++ functionality with QWidget only, and QML with JavaScript only.
Most future desktop applications which go with QML for all or part of their UI will most likely continue to use the trusted Qt/C++ library for all of their underlying functionality and data handling.

Think of QML as the next generation of .ui files. You can use it heavily, or only a little, or not at all.

Sure, the Trolls have a vision of QML becoming heavily used by many developers (because they’re really excited about it and convinced that it’s awesome), but – especially thanks to Open Governance – which parts of Qt will actually see how much maintenance and improvement in the future will not depend on today’s visions, but on the actual developer needs that present themselves in that future.

Stop worrying!

Stephen Chu says:

@ary
Stop accusing people of “spreading FUD.” What benefit do I gain from doing that? You think I am an operative of some competing organization? I have my legit concerns and I am allowed to express it. You don’t own the truth and you can’t predict the future.

I know the new “Open Governance thing.” And I also know it doesn’t magically bring Qt unlimited resources. And Trolls will still be in the lead, owning the project or not. Their direction matters. In the future when C++/QWidget bugs and MRs are left rotten in the system because all the best and brightest are working on QML, do you think the project will still attract contributors in that area?

And saying QWidget will still be available is ignoring the fact that it will be on top of different platform interfacing layer than it is now. No one can guarantee it’s going to be smooth sailing. When things don’t go so well, it will have to compete with QML for resource, open governance or not.

Sure you can mix and match QML and C++. But why? Again, what is in JS/QML that can do that C++ and a new QWidget replacement can not?

SABROG says:

For now i see few main problems personally for me:
1. Can’t using RDP (generally i using Remote Desktop on my work via internet, so huge traffic and slow raster rendering can be big problem). Now i know what i can use (deprecated for Qt5?) QWidgets and tech support doesn’t want help me if i found bug in old paint system…
2. Lerning JavaScript. If before i can just ignore QtScript module, now i must spend more time for learning new syntax. I don’t say what is bad, it’s just there.
3. Drivers. In office only I have good nVidia graphic card buying for myself. Other computers have integrated Intel graphic chipset, which doesn’t support shaders and exists only drivers with OpenGL 1.4. I try install MESA drivers for Windows when try run Angry Birds, but with no success.

Generally i like idea, and have a small suggestion. How about create “redistributable” package of Qt5 for Windows? When I want download program written with Qt library, I again and again must download ~10-20Mb Qt .dll’s different versions.

Fazer says:

Sabrog: “Generally i like idea, and have a small suggestion. How about create “redistributable” package of Qt5 for Windows? When I want download program written with Qt library, I again and again must download ~10-20Mb Qt .dll’s different versions.”

That’s not Qt’s problem, but Windows’ not having package system. That issue applies to every library that is not shipped directly with Windows.

Stig says:

QtCloud. QtServer. QtService.
Many software systems exists partly as a device-software and partly as server software.
Future Qt/QML should make it easy to write device and server software with one language pair and in one development environment.
( QML-JS/C++ in QtCreator )

QtEverywhere (including the Server)

MNaydenov says:

@Bnilsen about “unless you develop something that is visible on the screen” (you can use C++)

Well that is exactly my point. To be able to “draw from code” is *needed* for everything non-trivial (or already handled within the ready-mades).
Even Flash (which is a *designer program*) added drawing calls to actionscript 10 years ago, and “by coincidence” this created a real explosion of cool and innovative content (which opened in the visual editor was nothing more than an empty clip at the center of the stage). The point is with a designer tool (or language) you can only (re)create a limited number of predefined scenarios.

Now about “no prob you can create your c++ declarative items programatically and have all the power you need”.
Well, at least for now, it is not worth it! It is like creating every new QWidget to be compatible with Designer…or to be a plugin. The point is, there is a development overhead for all this “declarative” stuff, which for non-trivial stuff is not needed in the first place.

Jason K says:

I for one really like what I’m hearing. QML with ‘native’ styling/components on top of a highly optimized scene graph and portable via an abstraction layer (lighthouse) will be an _awesome_ platform. Move over WPF, Silverlight, and Flash!

ary says:

@Stephen Chu

“Stop accusing people of “spreading FUD.” What benefit do I gain from doing that? You think I am an operative of some competing organization?”

Nah, I just think that people are naturally susceptible to FUD and pass it on without meaning any harm.

“I know the new “Open Governance thing.” And I also know it doesn’t magically bring Qt unlimited resources.”

But it does steer resources towards areas which Qt application developers care about most.

“Sure you can mix and match QML and C++. But why? Again, what is in JS/QML that can do that C++ and a new QWidget replacement can not?”

It’s not that pure C++/QWidget can’t do certain things.

It’s just that certain (UI-related) things can be achieved much *faster*, *easier*, and in a much *cleaner* and *reusable* fashion, by using QML.

Modern “fluid” UI’s with fancy composited transition animations and bling-bling are one such thing, but by far not the only one.

Another one is, for examples, complex widget layouts. QML’s anchor-based positioning of items and property binding for position/size properties makes many thing very easy which are rather difficult and complex to achieve with QLayout subclasses.
Even the most boring, static business application can benefit from this if it needs to lay out many widgets relative to each other in peculiar ways.

Also, things like “states” (which I consider a very useful UI development feature, even if you don’t use any graphical transitions) are an implicit feature in QtQuick and therefore much easier to access than e.g. by manually integrating QStateMachine with your QWidget UI.

And I expect to discover many more nice surprises, especially once Qt 4.8 is released…

Sergey says:

So now, with all that JavaScript bullshit going on – may be we should drop Qt as obsolete and start to write html code for browsers? Same cross-platform, same “powerful” language…
Too bad for those of us who needs high performance applications. -10 points for Qt for new development projects (in addition to -50 due to Nokia/Microsoft issue).

otengim says:

As many people said here Im not agree or Im afriad of all QML and Javascript thing, I use Qt cause is based on C++ foundation and it can be programmed with full OOP and debugged etc. I would like to see Qt supports C++11 with lambdas and the good stuff is coming from the new spec. Its time to drop the preprocessor for signals and slots, for legacy systems people could still continue using Qt 4.x.

PLEASE don’t do full steam on javascript and QML, FOCUS on C++, Qt is C++. People via plugins could attached their language of choice to use the QML and that stuff but we C++ developers we are not interested on javascript or qml etc.

otengim says:

Sorry for second post but I have to say this. For people interested in fancy web UI with a scriptinng language as javascript I invite you to use Flex and Flash, It is awesome tool with lots of years of experience with web development and backed by one of the best companies focused on web and UI/Graphics they know what they are doing. Again I dont agree that Nokia or the Qt team focus in something that have to compete to Flex/Flash, Silverlight, etc. makes no senses.

We use Qt because it is based on C++, High performance and native compilation and because C++ rocks and more will be with the C++11.

damian says:

@Everyone hating qml: I’ve also had my doubts, but the thing is that you can make a normal c++ app, and only use qml where youy would use Qwidget objects, and learning Qwidget classes and properties should be the same burden than learning qml, even with the small syntax changes, it does not mean learning full javascript if you don’t want to.
But it will take time to get qml to the state in which any app would benefit and work good when using it, but that’s why qwidget will still be here a long time, first port the apps that would benefit, then make qml better, port more apps that now would work better with qml, and keep doing this cycle until all apps are qml.
So “the burden of learning 2 languages” doesn’t seem big, actually by what I’ve seen, it seems easier to understad than qwidget stuff.
Also about performance, people seem to believe their buttons will be drawn by an interpreted language, but as far as I can understand, they will be rendered by good compiled c++ code, only the call to that code will be qml.

Hermit says:

>You don’t need to read QMLs from disk. QML can be integrated in the binary as any other resource can.

Guido Seifert, that wasn’t the point.

Hermit says:

(forgot this)

>QML is an extension to JS. Take the core (JS) away from an extension (QML), leaves you with…?

Erik Verbruggen, that leaves me with C++ and none Javascript crap. As a language it sucks. Why would I want to use it at runtime to handle UI if C++ does it just fine? Can’t C++ add, subtract, multiply values or what’s not? Javascript is not needed there, unless you read it from external source (as in ‘pluggable interfaces’).

flc says:

相当期待!

RupertFromAfrica says:

@Lars
Great plan!

@Everyone beating the c++ drum
I really like Qt’s c++ APIs. They are (for the most part) great, intuitive and clean. That said:

1) I hate .ui files (generated code is evil)
2) I am not a fan of Qt Designer (the tool)
3) I am not a fan of cascading layouts and ownership of objects in c++ to get just the right layouting behavior
4) I have tried QML (without any background in JS or web related tech) and I find it fantastic. I can’t think of a single situation where I would rather use Qt’s traditional paintevent or specialized widgets, even for a spreadsheet application. It would take several shattering experiences to drive me from QML back into the arms of QPainter, QWidget and friends.
5) Open Governance has solved the problem of “Too many mad scientists, not enough hunchbacks”. If you want to see something get done, pitch in
6) The Digia transition has given commercial customers a clear entity beholden to their needs and responsible for actively developing the areas they want developed.
7) It is a competitive market, we need to make these changes to evolve and stand a chance of competing in the embedded space. Android is dominating this area now in all its fixed, quasi-open, non-extensible, Java fueled glory. We need to be on top of our game, and designing to the lowest common denominator is not how you get there.

@Every/Anyone
Can you see anything clearly missing from this roadmap/blueprint that would help to future proof Qt?

@OpenGL opposers

OpenGL won the war. OpenVG is dead (was it ever alive?) and most low end targets from chipset vendors traditionally shipping DirectFB boards are coming with OpenGL ES 2 support these days. Shady OpenGL drivers on Linux are more common than spots on a leopards rump, this needs to get fixed, not ignored or worked around.

Robert says:

Okay, I’ve slept over it. Maybe QML isn’t the devil incarnate after all.

But one question to all the QML experts out there: Has anyone tried something like the 40000 chips demo in QML? How does it compare to the pure GraphicsView demo performance-wise?

(Note: We are using industrial hardware without graphics acceleration, and will probably do so for a while still. I doubt SceneGraph will not solve my performance issues for me. GraphicsView is probably about as optimized as possible without graphic acceleration, so how should SceneGraph do any better?).

mireq says:

What is the QML equivalent to:

QVBoxLayout *layout = new QVBoxLayout(this);
layout->addStretch(1);
layout->addWidget(new QPushButton(“Button”));
layout->addWidget(new QPushButton(“Looooooooooong text”));

with all constraints (minimum size of widgets, minimum size of window, default spacing …)

TheBlackCat says:

Even if Qt developers don’t want to develop QML implementations in other languages like Python or Ruby, at the very least it would be good to structure it so it is as easy as possible for other people to create alternative implementations for other programming languages. This probably would require separating out the underlying logic from the javascript components (this also follows with the modularization that is a goal for Qt 5). My understanding is that QML is currently structured in such a way that it is impossible for it to be implemented in other languages. I think fixing this should be a major goal.

Even if Qt developers don’t see the benefit to having it in other languages, other people obviously do, so the people who want to implement it in another language should be allowed to do so. At the very least I have seen interest from python developers in making a QML implementation, but they are currently blocked from doing so because of how QML is structured.

At leat my interpretation of open governance is not just about governance, it is structuring the Qt code to make it easy for third parties to contribute. Structuring QML so it is impossible for third parties to make their own implementation seems to go against this philosophy.

Thomas Hartmann says:

@TheBlackCat:

Qml is tightly integrated with JavaScript and just JavaScript and there are plenty of reasons for that.
But I can ensure you: There are already people out combining Qml successfully with for example Python.
Using Qml does mean that you can do logic in JavaScript not that you have to do the logic in JavaScript.

Thomas Hartmann says:

@mireq:


QVBoxLayout {
         QStretch {}
         QPushButton {
              text: "Button"
         }
         QPushButton {
              text: "Looooooooooong text"
         }
}

Actually Qml really works with QWidget, but is not officially supported (Internally we use it for the property editor of Qt Quick Designer http://labs.qt.nokia.com/2011/05/05/qt-quick-designer-in-qt-creator-2-2/).

The official story will be Qt Desktop Components (See: http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/).
Qml with traditional Widgets is already very flexible and useful. You can be sure that the Qt Desktop Components will be even more so.

Some future version of QtCreator will use Qt Desktop Components and we will eat our own dog food and we will make sure typical desktop applications will benefit from Qml.

Qml is basically just the next step from .ui files and nobody will force you to do any JavaScript coding if you do not want to (All the logic can be C++). Nobody will stop you from using .qml files just like .ui files.
But adding bindings or a few lines/functions of JavaScript often makes things a lot easier and you absolutely do not have to be a JavaScript expert to do that.
Also instead of sub-classing in C++ it is often easier and more convenient to just define you own custom qml component. This approach usually requires far less boiler plate code and is way easier to maintain.

Just get familiar with Qml (does not take long) and you will see and understand the opportunities.

max says:

QT learn something from microsoft, like WPF, silverlight, WCF.
I hope Qt can develop web service programe.

David says:

Guys anyone tried QML for heavily loaded GUI? How does it performs? Is there any performance degradation? If primary focus is on QML and widgets are left for backward compatibility only, desktop developers should know how QML performs. Should we invest in it or abondon Qt at all

yun says:

Good to know QT has new plan.
In the next version. I hope it will be more convient.
Hope more features like Eclipse.
Such as create #include automatically, promt known used functions and so on.

André Pönitz says:

@yun: This discussion here is about “Qt, the tool kit”, not “Qt Creator, the IDE”. For feature requests on either please consider using http://bugreports.qt.nokia.com.

igor says:

qt is (was) primarily used for portability and speed, build it around qml (java script) and one of reason to use it is gone, there is plenty of “good concept but terrible implementation” libraries for java and c#, suspect many of people will either choose native libraries for new platform (cocoa, etc.) or go for java and java’s libs or c# and silverlight, not sure why is this being done, why imitate android, if we target java use java’s libs why expect that people will choose qml ? seems to me that nokia is completely discarding initial reason for qt existence and making it into qml portable device platform. clumsy programmers win again, everything is being adjusted towards programmers who cannot remember to close a file, release memory, learn sophisticated concepts …

FF says:

The direction is clear. QML should be the new Flash.
Hopefully it will be faster then Flash, then that is the biggest drawback with scripting stuff.

But when I looked into the src code of the QML SceneGraph, I thought WTF?
Several Node classes over Node classes, that is so 90′s OOP.
Please use the KISS style.

Mohamed-Ikbel Boulabiar says:

Someone should thing of using jquery + writing another lib to make QML files drawble on web browsers.

ary says:

@Robert: “Has anyone tried something like the 40000 chips demo in QML? How does it compare to the pure GraphicsView demo performance-wise?”

That’s an interesting question indeed.

Maybe if the Trolls would release a well-performing QML-version of this demo (or a similar one) with the next Qt release, it might clear up a lot of doubt and fear.

Tyler says:

Our organization wrote many lines of code using QT 2.x and QT 3.x. As such, we’re still heavily relying on Qt3Support-based classes and function calls. There is no mention in this article as to deprecating support on the Qt3Support module, but it is still a vital piece of our framework. Are there some changes planned we should prepare for?

ddenis says:

ikbel: something like Google Native Client port of Qt? ;)
http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/

Nikos says:

I don’t like where this is going :-/ From a C++ toolkit, to a JavaScript toolkit for mobile devices.

This is not Qt anymore.

Jason K says:

OK, so some people are upset about the QML focus – apparently due to the assumption that QML == Javascript (and the knee-jerk reaction to this is that it implies slow and dumb)? Or is the scene-graph based approach? I don’t quite see either concern.

In its most basic form, QML reduces to a JSON syntax for creating a QObject (thus QWidget) tree, and so replaces the current UI files. What’s so bad about this? The great thing is this approach also then accommodates use-cases others of us might have, be it whiz-bang UIs, prototyping, etc.

As for the scene graph, the white paper makes it clear existing QWidgets will use the Raster or OpenGL-based engine [so likely looking very similar to today], whereas QML uses a SceneGraph optimized to reduce GL state changes, etc . This seems an ideal situation to me: with the current approach switching to the OpenGL often yields no performance gains (and sometimes is even slower) for example in various QGV use-cases on Win32 vs. raster.

In embedded world, do you have any plans in continue suporting/improving QWS?

Mark Kasson says:

I’m with Nikos, J Puhr and several others above. The GUI portion of this reasonably fast, highly capable C++ toolkit is changing its feathers toward a multi-language, partially interpreted rapid prototype development tool.

I, too, am concerned with the multi-language aspect, especially involving what appears to be interpreted languages. Our UIs, like others here, need to be fast, not fancy, and are quite data intensive. Picture tables and forms with large numbers of columns or fields. If there’s stuff to be implemented, I need it in compiled C++, not interpreted Javascript. The stuff that was only available in CSS was already slowing things down. This is to say nothing of the need to know multiple languages and the Tower of Babel that results.

Please don’t remove the GUI ability to build a tool for desktop 1apps that deal with real world significant amounts of data in favor of being able to rapidly develop car dashboards and mobile apps. I’m not saying don’t have both; I am saying please don’t kill the former.

J. Puhr says:

> OK, so some people are upset about the QML focus – apparently due to the assumption that QML == Javascript

No, that’s not correct. As mentioned, the proposed concept will *increase* (and not decrease, as the article claims) complexity. You have to be familiar with the topics that your application handles (the core business), plus C++ (which is very deep), plus JavaScript, plus this new markup language. Plus CSS, Plus the Qt-C++ concepts that are not common C++ concepts (MOC-compiler, QObject, Qt’s own container classes, etc. etc.).

Rule No.1 in Software engineering: Keep the complexity simple. It will rise without somebody being involved.

C++ is OK if and only if one knows what he’s doing. The C++ standard library has not much content compared to (for example) the huge .NET library. The solution is (at least until now): Qt. It fills the gap to develop C++ GUI applications, but it seems that they will go their own way in the future.

lapol says:

Hello again,
it would be very kind if my open question would answered:

What is the future of QGraphicsView? Is it considered “feature complete” (defacto will only get critical bug fixes just like QWidgets) or will it be actively improved (from Nokia not some potential outsider)? How does it fit in the scene view logic?

What is the stance on remote sessions? Are they now officially completely unsupported and not regarded in ANY conceptual planning (again from Nokia, not from the community)?

Thanks.

Bnilsen says:

@lapol and others

A follow-up post is now published, so please read it. It clarifies a lot of confusion. http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/

Konstantin Tokarev says:

@ddenis: Lighthouse itself cannot completely replace QWS – e.g., it does not provide window system at all!

Karthik says:

Hi Qt5 devs,

Congrats for all successes. But please remember to implement qprinter-multiple-pages-with-range and print-current-page in the print dialog. This was really poorly done in QT4.

Many thanks,

J. Puhr says:

Sometimes some upper management of our company ask why we “still” program in C++, because Java and C# dominate the market in libs, tools and job-seekers skills. Then we answer, that we have some time critical parts in the software that need to be written in C++ (not admitting that no less than IBM has created an Java VM that supports hard real time…). Then the next question: Why not the app logic in C++ and the GUI in Java/C#. The answer: Because it simplifies the software, having only one language.

If I make the step and divide my app into parts with different languages, why should I choose for the GUI part QML?

Danny says:

First off, Qt is fantastic and it’s nice to see it continuing to evolve.

Some things I would like to see in a future version of Qt (no particular order):

1) Replace all usage of ‘int’ in containers with 64-bit friendly size_t, just as in std. It was a mistake to use ‘int’ for so many things in Qt and we have to cast all over the place to avoid warnings on 64bit.
2) Fix qmake. It doesn’t scale well and getting it to work on non-trivial products requires hacky undocumented variables and tricks (see QtCreator’s own pro files). If you can’t fix it, switch to CMake.
3) Fix QVariant. Seriously this class has caused us many problems, particularly the compare-by-address design for custom objects and imprecise conversions.
4) Throw away MVC classes and start again. The existing classes are cumbersome, over-complicated and assume all data can be distilled into lists, tables or trees which just isn’t true (e.g. graphics apps). We have to use our own models and the slow widget-convenience classes with heavy custom widgets for our applications.
5) Fix Mac OSX port. Qt applications still do not look native on OSX and require a lot of polishing.
6) Provide real XCode integration. Creator is nice but it still can’t compete with the big boys. However the current XCode ‘integration’ is a joke. Rebuilding the entire project every time a moc-able class or resource is added is a deal-breaker and makes OSX a second-class citizen.
7) Add simple Core-Animation style animation to widgets. The only options right now in Qt seem to be the state machine or QML, both of which require re-writing huge amounts of code.
8) Provide a document framework which provides multiple documents, undo, save and search, registration and auto-updating out of the box. Right now we have to code all these things ourselves. Even MFC had a document framework.
9) Replace all bald-pointers with shared pointers (shared_ptr, not the broken QPointer).
10) C++0X compatibility.

mannd says:

This post contains one of the most awesome split infinitives I have ever seen.

charley says:

@Danny– I’m a huge QML fan, but yours is a great list, especially points on qmake and MVC (they need to have value-semantics for handles that reference into the developer-specific models).

aiger says:

@danny: 1) using platform-dependent sizes means you can’t use QDataStream to exchange data anymore. that is much worse than restricting item count to 31 bits. even with plain char that’s a 2 GB blob (possible perhaps), with anything larger it looks like a rare case. 2) cmake is as quirky as qmake. not much to be gained by a plain swap. a real solution would be nice, though. 3) compare QVariants only when they are of the same type, not cross-type. problem solved. 4) “throwing away” certain widgets is not an option. an alternative might be welcome, though. 6) disagree with the Creator judgement, but hey, use XCode if you like. 9) would be stupid to waste cycles for no good reason. being afraid of bald pointers is not a good base to use c++, especially if the framework takes care of most lifetime management issues. 10) there are already things like Q_COMPILER_RVALUE_REFS, Q_COMPILER_VARIADIC_TEMPLATES, Q_COMPILER_AUTO_TYPE, Q_COMPILER_LAMBDA etc in the code.

Thiago Macieira says:

Hello everyone

Answering the comments here is getting very difficult. There are many topics to address and we’re sure letting things fall through the cracks in the more than 230 comments made to the two blogs.

I’d like to ask people who have thoughts and ideas about Qt 5 as well as feedback on the plans that Lars outlined to subscribe to the qt5-feedback mailing list and post there. We can address your feedback better there.

Link: http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Commenting closed.