Qt for Android Automotive 6.5.2 リリース

Hi Andy,

great post. I really would like to to give QtQuick a try. For my application I would like to implement some kind of graphical programming like it is known from LabVIEW. That means, there are processing nodes (rectangles) that are connected by data wires (lines or splines). The use adds nodes, connects to nodes via wires and drags nodes around with the mouse.

Do you thing, this is possible with QtQuick? I have an Idea how to do it with QGV but not how to do it with QtQuick.

Very nice post!
I am happy to hear that a policy change of private QML APIs is at least being considered.
Despite really liking QML and Qt Quick in general, it's one of my biggest gripes.
When I make applications using Qt Quick I want to keep my user interfaces completely declarative and put all the imperative parts and logic in C++.
A completely public C++ Qt Quick API would help a lot in this.

What about memory use? From what little I know of QML, almost very primitive like Rectangle inherits from QObject, and usually with QML your objects are compound objects with Text as well. To use QML instead of QGraphicsView for a application that requires lots and lots of graphic items seems to spell out a huge jump in memory usage for QML.

We are using QGraphicsView heavily in our application and also offer Python scripting to script your own graphics view. So moving to QML would mean to say to all the customers,
forget your old scripts, do something new! And it works almost as good as the old things... But you can't embedd widgets anymore.... But you can learn how to use QuickWidgets1 no, wait, QuickWidgets2, or something that will come next year and will be around for a year or two...

Hm, to me this is too much change in a short time. I understand that you have to move forward and that some architectures can't be fixed, but it is not so easy to tell everybody to just don't use working APIs anymore because people have large working applications.

Sorry that I sound like an old person who says everthing was better in the old times,
but I really think that you should focus on longterm APIs and not things that get introduced and shortly afterwards they are deprecated again and people who used them are stuck at an old Qt version.

Guys, I'm with Qt from 2012 year and I love Qt absolutely. Every day I'm trying to spread Qt everywhere it is suitable. But what are you doing? Qt is C++ Framework. C++ needs Qt and Qt needs C++. Qt is not JS framework and not scripts toolbox. Why do you trying to move from QWidgets?

In section "But I don't want to write QML or Javascript!" the only two argument you used, substantially, is "Give QML a try" and "Writing only C++ can be challenge". And both of them is your opinion (I mean your company). It can be challenge because of your decisions, not because we need so much QML and it is so cool. It's because company has a plan to move from QWidgets to QML, nothing else. Stop that, please. We need C++, not one more script. Enough scripts in the World.

One specific question:
When I don't understand a certain behavior in QGraphicsView, I add some breakpoints and step through the Qt code. I follow the state changes, paint calls, etc. and usually see what's going on.

How would I do that in QML?

Do anyone use qml to create big apps? qml is a neat tool for "mobile like" apps, I use qml to create some small apps for in house use(experiments). Conclusion is I always find QWidget, QGraphicsView are better tools for large, industrial products.

1 : it is more mature, more tutorials, examples, easier to create complicated apps. Mobile screen is not suit for that kind of apps but favor more on simple, fancy UI, which makes qml a decent choices

2 : compile time checking is very essential for medium/large size projects, type safety help you avoid lots of subtle bugs.

3 : it is easier to control resources by pure c++. Why should I scratch my head to optimize 40000 chips on screen by qml when QGraphicsView solve this problem perfectly?

4 : I can control scope with much better granularity by c++. It is hard to imagine how could I keep things maintainable with qml.

qml advertise so many years, yet it still do not looks like a decent tool for complicated app compare with QWidget/QGraphicsView. What is the future of Qt?

a : Make qml easier to replicate all of the things done by QWidget?
b : make qml as a neat tool for fancy small app while maintain QWidget?

ps : allow users to use QtQuick by pure c++ do not mean QtQuick become better candidate than QWidget/QGraphicsView if it still lacks those features QWidget/QGraphicsView offer.

I really like QML and Qt Quick. The declarative nature of the language, the data bindings, the animation system. This is all very convenient for quickly building fluid, animated UIs, which are a pleasure to look at. I really like having tools like this at my disposal. Modern, touch-optimized, fluid UI is a major selling point, because looks sell better than anything else. It also fits the mobile and automotive segments. It is obvious the Qt Company wants to pivot into these segments and therefore is pushing QML hard.

But there is still a big use case for QWidgets and QGraphicsView in desktop applications, CAD-like programs and industrial GUIs. These applications simply cannot and will not be replaced with fingerpainting consumer-grade UIs. QML is simply not a good fit here for all the reasons already mentioned in this discussion (and some more). Yes, a lot of issues can be worked around. But then you may come to a point when that is simply too much to work around and you ask yourself "why bother?", when QWidgets worked well for you.

As a developer who relies on QWidgets & QGV heavily, it is distressing to hear that the Qt Company might be obsoleting this technology. Especially when there is no good alternative out there. Please, don't do that and don't treat QWidgets and QGraphicsView as second-class citizens. Thanks.

Thank you everyone for the comments so far. We do read each comment and there have already been some interesting discussions as a result.

@Qt I uploaded on Github https://github.com/FabriceS... a demo application that implements shaders for theses vector graphic primitives:

• markers
  
• arrow field
  
• quadratic bezier curve
  
• cartesian grid
  
• polar grid
  
• hammer grid
  
• transverse mercator grid

A shader for dashed polyline is also known but not yet implemented in this demo. For example, I implemented polyline curve based on geometry shader from tablet input in another application.

Theses experiments are impressive but vector graphic on OpenGL is not an easy task. There are issues. But the ideas beyond QML scene are right, we have to optimize the opengl pipeline to achieve good performances.

I think developers need concrete examples to know if a technology is mature enough to use it for real applications. On Qt4 things seems clear despite there are many flaws, but in Qt5 it is more confusing since it is steel a new approach.

There are more than just simple UI widgets in computer graphics. We have extensive customized QGraphicsItems for our graphical editor product. On top of custom items, calling through to JavaScript and back to C++ is not optimal since speed is one of the very top requirements for it.

Your blog post was a little bit late for the QtCreator team. They just implemented Qt SCXML and State Chart Support in Qt Creator. I was shocked to see that they used QGraphicsView for the graphical state machine editor. This could have been such a great example of how to use QtQuick in a professional product instead of QGraphicsView.

What is your opinion? Would it have been easier and better to implement the State Chart Editor with QtQuick?

I agree with a lot of the anti-QtQuick opinions expressed here. Please understand that software has an extremely long life cycle, much longer than most people think. I'm currently replacing a 20-year-old GUI that was written in C with straight X11 calls; the rest of the application is actually fairly modern C++ by now. I was evaluating QT5 with QGraphicsView to replace the GUI portion, and it looks very appropriate and useful. Then I came across this page. I have never heard of QtQuick until now and after reading as much as I can find about it -- Do Not Want. Why make your own markup language for this stuff when the C++ classes already work? I can be fairly sure that if I use QGraphicsView, others will understand the C++ code 20 years from now even if I have to keep a by-then ancient version of QT around to use it. I can't be as sure that people will know what to do with this QtQuick thing. The selling point of "oh you can do things with QtQuick that you can't do with QGraphicsView" rings hollow when I never intend on doing any JavaScripty type stuff with the application in the first place.

I have spent quite some time in the last weeks evaluating Qt Quick / QML as a possible choice for new UIs, or even as a possible replacement for existing UIs (which are currently done in Widgets or GraphicsView). That evaluation gave me a pretty clear picture about where QML is usefule, and where it is not:

QML is useful in UIs which are designed, i.e. you know at design time how they are supposed to look and behave. Examples: An app for chatting; A calculator; A typical dialog; A file manager GraphicsView is useful in UIs where the user creates the design at runtime. Examples: An application for creating presentations (e.g. PowerPoint), A vector graphic drawing application, A layout designer for electrical components

Maybe GraphicsView has been misused in the past for things it was not really great at, and it makes sense to replace it with QML in those cases. But it really shines in the examples I gave above.

Still....the QPainter stack is getting old and slowing things down.

So my hopes are for step-by-step extensions on the Qt Quick / SceneGraph level, so that one day, I can replace GraphicsView with C++/Qt Quick/SceneGraph, and easily integrate the result into a QML scene

Well, I got a little scared with the title of this article. Because I'm building some widgets of my application with QGraphicsView.
However this made me remember that a friend of mine said that Qt is slowly giving preference to Qml instead of QWidgets, so this change from Graphics View to QtQuick should not be a surprise. But maybe he can be wrong. However my adventures with Qml wasn't the most pleasant ones, and for now I'm still giving preference to QWidgets.
I enjoyed your post and I'm looking forward the next ones!

QtQuick is cool and nice (I like it a lot). But not being able to print (as simple) as QWidgets and QGraphicsScene is a real issue. And yes - having Rectangle as the only shape is annoying (but no big issue).

"There was a time when the Qt Graphics View Framework was seen as the solution to create modern user interfaces with Qt."

Yes... That's sort of true. I've always felt that that was an abuse of QGraphicsView, though, and a big mistake back in the Nokia days. When QGraphicsView was being developed, Lars suggested to me that it would be really good to use it to render the documents in KOffice. It was originally a canvas implementation, replacing the old Qt3 QCanvas class. You'd use it to render the document area of a word processor, mapping application or spreadsheet, not to create a finger-friendly gui.

Me and my team are heavily dependent on QGraphicsView, and have a huge codebase building on it. There are several reasons for that:
1) For various reasons, we still work with Qt 4 exclusively.
2) Our only performance-critical use cases run on a custom embedded hardware. I have my doubt that QML would improve anything there (no GPU, no FPU)
3) Our whole toolchain is tuned for C++. For example, our code is checked by static code analysis. Are such tools even available for QML?
4) As mentioned, there is a huge codebase that would need to be changed. The benefits of spending several human-months (given our level of customization maybe beyond a human-year) to exchange a proven system for a new one needs to be so clear that also non-technical decision-makers can get behind it. Currently, I see no such clear advantage. Rather the opposite: Because we have very long-term support on our products, replacing GraphicsView would mean that we have to maintain two very different codebases - with all the extra cost associated with it.

In any case, I would probably need to spend weeks toying around with QML to just find how the various customizations we currently do in GraphicsView would be replicable.

Nice post, I'm glad to see this subject discussed on the blog. Personally, I think the old QGV demos and examples were more inspiring for my use-cases (desktop, maps or CAD oriented). Perhaps porting (or rethinking) a few of them (10k chips, diagramscene, ...) would help to demonstrate the advantages of QSG and give insights on design choices or migrating from QGV apps?