Andy Nichols (nezticle)

Should you still be using QGraphicsView?

Published Thursday January 19th, 2017
36 Comments on Should you still be using QGraphicsView?
Posted in Dev Loop | Tags: , ,

There was a time when the Qt Graphics View Framework was seen as the solution to create modern user interfaces with Qt. Now that Qt Quick 2 has matured does the Graphics View Framework still have a place in Qt?

At the Qt World Summit 2016 I gave a presentation entitled “The Curse of Choice.” It gives an overview of the various GUI technologies available in Qt 5 as well as descriptions of which you should use for different use cases. I would recommend you watch the recording of the presentation, unfortunately there was a technical issue with the recording and while the talk is available for viewing online, it is incomplete.  I did give the same talk in webinar format though which you can view here.

After each time giving the talk, I got many questions about the Graphics View framework, which I was quite harsh on. My conclusion was that users should avoid QGraphicsView for new applications and instead use Qt Quick. This proved to be a controversial claim because Graphics View is used in many applications shipping today. So in the interest of answering the question “Should you still be using QGraphicsView in 2017?” This post will give the longer form of the answer.

Prophetic comment on a post about Qt Scene Graph

Prophetic comment on a post about Qt Scene Graph

Does Qt Quick really replace Graphics View?

Yes and No.

Qt Quick 1 (QDeclarative* API) was built on top of Graphics View, so comparing Graphics View to Qt Quick 2 is like comparing apples to oranges.

The better question is: “Does the Qt Quick Scenegraph replace Graphics View?” The lessons learned from using Graphics View for Qt Quick 1 were applied to create its successor. An API optimized for rendering Qt Quick scenes on devices with a Graphical Processor Unit. That API is the Qt Quick Scenegraph.

Qt Quick and its Scenegraph API can do most of what Graphics View could do and much more, but there are still features that got left behind:

Graphics View enables Multiple Views of the same scene

This powerful feature was shamelessly flaunted in the 40000 Chips demo:

40000 Chips Demo

The Power of Qt Graphics View!

Because all items in Graphics View can live in a shared QGraphicsScene, it is possible to have more than one QGraphicsView widget each of which could display different views of the shared scene. This is quite difficult to replicate in Qt Quick 2 because each view would need to create its own copy of the scene.

A cool as the feature seems, in practice it was not used so much by customers. The feature was also less practical on mobile and embedded platforms where only one view would be used per screen. This proved to be an unfortunate design decision because it also limited opportunities for optimization.

It makes the code really complex and optimization hard. — Alexis Menard ( Qt DevDays 2010 )

If you need to show the same scene multiple ways when migrating to Qt Quick, then you will need to separate the data you would like to visualize from the scene defined in QML. Populate each Qt Quick scene with only the data present in the view of your logical scene. This is more complicated but does provide more flexibility in how you store the state of your shared scene. I concede that it was easier to do in QGraphicsView.

Graphics View depends on QPainter

This is both a blessing and a curse. One of the reasons that Graphics View lived on so long through Qt Quick 1 in Qt 5 is because of its use of QPainter. When Qt Quick 2 was released with Qt 5.0 it came with the requirement that it could only be rendered with OpenGL(ES) 2 or higher. This minimum requirement did not fit everyone’s needs, and the solution was to keep Qt Quick 1 around for those customers.

In Qt 4 QPainter had a couple of different graphics systems (backends) that could be used. This meant that if you were rendering with QPainter you could either choose to do so in software (raster), or with the GPU (opengl). In the case of QGraphicsView if you wanted to render your scene with the OpenGL paint engine you just needed to set the viewport of QGraphicsView to be backed by a QGLWidget.

In general this would improve the rendering performance of Graphics View. However, under the hood QPainter is generating loads of state changes and rendering the scene back to front leading to a poor use of the GPU. This is a large reason why the Qt Quick Scenegraph exists. In Qt Quick the renderer can, depending on the scene’s content, determine the best way to arrange the scene for rendering on the GPU.

Qt Quick as of 5.8 no longer requires the use of OpenGL 2 thanks to the Software rendering adaption.

Graphics View has collision detection

What! Are you making a game now?

Angry Birds

They use Box2D, and so should you.

Graphics View supports embedding QWidgets

This is a neat feature and became a customer favorite shortly after its debut. The intention was to enable users to reuse controls that already existed. For simple widgets like QPushButton and QSlider the cost in extra memory usage and proxying was worth it for the convenience gained. However users did not stop there and would place complex widget hierarchies into their scenes like their entire QMainWindow or QDialog.

What was convenient for customers was also problematic for performance. QWidgets can not be embedded into a Graphics View scene directly. Instead they must be proxied. Each time an item in the scene that represents a QWidget requires an update, it has to request a full update of the QWidget via QWidget::render(…). The contents of the QWidget would then be rendered and copied into Graphics View. With Graphics View there is a shared QPainter between all items which renders to a single target QPaintDevice. QWidgets however are themselves QPaintDevices which require their own QPainter instances.

The key to the high performance of Graphics View is reducing how much is painted each frame. QGraphicsWidget and QGraphicsProxyWidget together are huge performance killers because they can not be rendered in a efficient way.

If you still choose to use Graphics View today, do yourself a favor and avoid embedding QWidgets into your scene.

QGraphicsProxyWidget: Not even once


Graphics View has Shape Items

Graphics View Items

As of Qt 5.8, Qt Quick still only has one built in shape, the Rectangle. The Rectangle Item can also be used to create circles, but that is little comfort to anyone porting Qt Graphics View shapes to Qt Quick.

You can create lines in Qt Quick with a thin and long Rectangle. Line segments become a series of Rectangles. If you wanted more exotic shapes or paths, then you have a couple of options:

Canvas Item: With the Canvas Item you can use the imperative Context2D Javascript API to render whatever shape or content you want.

QQuickPaintedItem: This is a custom C++ item that has a virtual paint method much like a custom QGraphicsViewItem. Here you can render whatever content you want but via QPainter making a very easy porting path from QGraphicsItem. Both this and the Canvas Item create an offscreen rendering surface the size of the area you want to render to. This can either be a QImage or an QOpenGLFramebufferObject.

Keep in mind that if you are drawing a large shape, there is also a large area of memory behind the scenes being used that will be the size of your shapes bounding rectangle.

Custom QSGGeometryNode: This is likely the most optimal method performance-wise, but also the most difficult. Rather than drawing the shape you desire though an imperative painting API, you would embrace the Qt Quick Scenegraph and generate custom geometry for your item. This however means turning the shape you want to render into geometrical primitives like triangles. The details of this are a bit much for this article, and likely best left to a future post. For more details check out this example.

There may be several ways to render arbitrary shapes in Qt Quick scenes, but none as convenient as QGraphicsPathItem.

Laszlo Agocs is currently researching this topic though, so as soon as Qt 5.10 there could be an easy way to use shapes and paths in Qt Quick. Stay tuned.

But I don’t want to write QML or Javascript!

Time to address the gorilla in the room.

Its very easy to breeze over the detail that not everything has a public C++ API in Qt Quick. If you are porting an application using Graphics View to Qt Quick, you will very soon realize that you have to write QML code. While you can (and should) use C++ APIs as much as possible with Qt Quick as well, you will find that creating sub-classes of existing components via C++ is not possible.

Lets consider the TextEdit QML component. If you wanted to create an item that extended the existing functionality of TextEdit you would have to do so from QML. The TextEdit QML component is implemented in C++, but that class is not public API, so you can’t use that class in your custom C++ item via aggregation nor composition.

Much of the Qt Quick QML APIs are like this. Even if you start with the approach of: “Code only in C++”, in practice this is challenging. We hope to address this in future releases of Qt. The original reason given to keep these classes private was to keep our options open, and not lock down these APIs too soon. As we are now releasing Qt 5.8 and looking towards Qt 6, its time to reconsider this policy.

That said, QML is awesome, and in practice extending items in QML is super easy. QML stands for the Qt Meta-object Language and should be looked at as an easy way to automate the process of setting up a hierarchy of QObjects and their signal/slot connections. If you’re holding out on Qt Quick because of QML, I understand, but recommend you still give it a chance. Check out the free online QML Book for more details on getting started.

Is Graphics View deprecated?

The short answer is no, not officially. The real answer is more nuanced. And it starts with the fact that Qt Quick 1 is now deprecated. This is important because it was Qt Quick 1 that drove forward the development of Graphics View. Much like the rest of the Widgets module, Graphics View is considered “done” and isn’t being given new features. You can see this if you check out the commit log for those classes.

There is some maintenance, but much of those commits are from various refactoring that covers all of the QtBase module.

Because of the larger than not overlap between Qt Quick 2 and Graphics View, I would expect to see Graphics View moved into a “Compatibility” module for Qt 6.


I am not so naive to believe that this answers all the questions you have about the future of Graphics View. I would like to continue the discussion because if there is a reason you still can not migrate from Graphics View, then we still have work to do.

If you want me to write more articles about porting from Graphics View to Qt Quick, please let me know in the comments.  Also if you recall seeing this post elsewhere, it also appeared on my own blog.  In the interest of making the Dev Loop of the Qt Blog more awesome, I’ll be posting all future blog articles here. So stay tuned!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Dev Loop | Tags: , ,


Lays says:

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!

Guenter says:

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).

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

Regarding printing Qt Quick scenes, this is something I’m hoping can be fixed now that we have the software adaptation as part of Qt Quick. The plumbing is not there yet, but it should be possible to render a QML scene via QPainter to a QPrinter paint device with the software adaptation. If enough customers/users scream loud enough then we can make it happen 😉

Marco Piccolino Marco Piccolino says:

WHAAAAAAA!!!! (I’m on startup plan – loud enough? 😉 )

sfabry says:

YEEEEAAAAAAAH (screaming as loud as possible…) we need this 🙂

Vote here:

Boudewijn Rempt says:

“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.

Robert says:

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.

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

Thanks for your feedback Robert! This is exactly the kind of perspectives I’m looking for. I understand why Qt Quick might not be the right tool for the job in your case. I mentioned it in my talk, but not in this article, but if Graphics View is working well for you now, you should feel under no pressure to change to Qt Quick. The take-away you should have as someone successfully using Graphics View now is that things will continue to work as they do now, but are not likely to improve. If there are regressions however you should put our feet to the flames 😉

Rémi says:

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?

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

I agree with you about the demos. As part of the research for this article I explored how it would be possible to implement a performant Chips demo with Qt Quick. I am thinking writing an additional post just about this process when I get time.

Marco Piccolino Marco Piccolino says:

That’d be awesome

Luke Parry says:

I agree with this.

I developed a QGraphicsView CAD (draft) interface in FreeCAD, which potentially could have models with 100s of lines of different types, each need to be selectable.

QtQuick2 is great for interfaces, but I am yet to see good examples that are relevant to industrial/engineering applications. Most examples provided by Qt are mobile interfaces/games, that don’t lend itself with the type of industrial work available.

The other issue is subclassing or the lack of public c++ classes that are available for QtQuick2, which surprisingly are available in the new Qt3D module which I like. The kind of ambiguity with prototype language in JavaScript/QML I find is difficult to lend towards a clean program structure. More structured examples/good practice guides would help in this area and encourage it’s use.

zzm says:

Yes, GraphicsView is very useful in CAD oriented development. There is little open source alternatives that is as mature as QGraphicsView. When we ported our codebase from Qt3 to Qt4, GraphicsView seemed to be a perfect successor of our own graphics layer. Luckiy we decided to keep the old graphics layer while kept an eye on Qt’s development. Now we are considering rewriting it using JS in browser. SceneGraph is good. But unfortunately SceneGraph can’t be used directly in C++.

Uwe says:

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.

Luke Parry says:

Yes this is achievable quite easily using QtQuick2.

Alexander says:

Hi Uwe,

I would really like to see something like this for Machinekit (, I have already QtQuick UIs: If you are going to implement this please let me know.

Best regards,

Uwe says:

Hi Alexander,

I have no glue how to implement this in QtQuick – I think I have to learn more QML and QtQuick before. The interesting thing is, that the new QtCreator comes with Qt SCXML and State Chart Support. And the state chart editor is quite close to the GUI I would like to implement. States connected via transitions – that is almost the same like nodes and data flow lines. And guess what the QtCreator team used to implement this editor:


tham says:

>And guess what the QtCreator team used to implement this editor: QGraphicsView.

This is a reasonable decision IMHO, QtQuick still far from ideal for that kind of applications after so many years.
QtQuick is decent for consumer apps, but never a nice tool for complicated, high performance industry products(ex : CAD tool), even Qt team know the truth and pick QGraphicsView for the new editor.

Thanks to the great works of those brilliant programmers put into QWidgets, QGraphicsView, even Qt company stop the development, they are still unbeatable if you are using c++, but this may change in the future.

Qt company asked us ditch QWidgets, QGraphicsView and embrace qml before it can fully replace QWidgets and QGraphicsView, this do not make sense at all, it is like talking “even qml is not a good tool for many desktop apps, you should use it instead of QWidgets and QGraphicsView, because they will become more and more obsolete in the future”.

You stop the development of QWidgets and QGraphicsView, yet never give us a decent heir of them. qml and QtQuick only good for consumer based app, fail to replace QWidgets, QGraphicsView on desktop apps we mentioned above.

So what are you trying to do? Make QtQuick be a decent heir of QWidgets, QGraphicsView in the future, or turn Qt into a library only good at mobile development?

Znurre says:

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.

David says:

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.

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

You are correct. In Qt Quick, any item you have in your scene is at least one QObject, so at the very least items in QML are closer to QGraphicsObject than QGraphicsItem. If you try to create the 40000 Chips demo by creating 40000 QML Components (each with many sub-components), you better come prepared with a lot of RAM! Normally you would avoid trying to create so many items at once in Qt Quick, by only creating items that were visible. But there are still cases where you need to have large numbers of items visible at once. The key is to have a Single (or few) QML items that have many QSGNode children. QSGNode’s are much closer to QGraphicsItem’s in the sense that they only carry a bit of state data, and don’t inherit from QObject. That is an over-simplified explanation, so I plan to write another post expanding on these things soon.

David says:

How to optimize memory usage with QML would be an excellent post. And an article on Qt Widgets and modern C++ would be nice too. I think most people using Qt widgets are still using C++98 with new and delete, but these kind of memory controls have been depreciated since C++14.

Florian says:

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.

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

Thanks for your feedback. This is balance we have to strike in many different places in Qt. Qt has been around for a long time, and has picked up a lot of different ways to do the same things. In general we only deprecate things that have been sufficiently replaced, and even then keep the old API around for quite some time. In the case of Graphics View it has been considered done and stable since Qt 4.8. The API will exist for all of the Qt 5 series, and will almost certainly be around for Qt 6 as well (though maybe in a Compatibility module, but thats just my speculation). If an API is currently working for you and your customers, there is no reason to change for the sake of the “new and shiny”.

WildChlamydia says:

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.

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

Qt is still a C++ framework and QtWidgets has not gone anywhere. We are not trying to replace QWidgets with QML. Qt Quick and QML enables the creation of a different kind of UI that QWidget could not support. Using QML in Qt Quick is similar to using UI files (XML) in QWidgets. Both are creating a hierarchy of C++ objects. It just so happens that QML also enables in-line Javascript code (which can be both a good and bad thing). I did not feel like I was advocating not using C++ in this article. Please do not take away the impression that we are trying to move away from being a C++ framework because that is not true. If anything I’m suggesting that we should do more to make the Scenegraph API usable from C++.

Robert says:

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?

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

In QML there is an additional debugger. So when you debug your application you have both the qml debugger and the c++ debugger running at the same time. In QML, since most of the structure is declarative it doesn’t make sense to set breakpoints, rather the QML debugger’s view updates in realtime to show you the current state of the tree. If you have in-line javascript code this is imperative, so you can set breakpoints just as in C++. These are two different worlds though so it does become more challenging to move from one to the other in the same debugging session. If you are implementing items in C++ (QQuickItem and QObject subclasses), then you would just debug as you are now. So for example if when you clicked a button in your UI, it would call a Slot on your custom object. Well then that is in the C++ side, and you would have a break point there. It will depend on the issue you are trying to solve which debugger you will care more about.

tham says:

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.

Martin Kutny says:

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.

Andy Nichols (nezticle) Andy Nichols (nezticle) says:

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

Fabrice Salvaire says:

@Qt I uploaded on Github 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.

FSCE says:

Very interesting piece of code, did you have a test with a pure QML interface with one QtQuick item per arrow or marker to allow selection and interactions and no application level AA ? Without a space partitioning and LOD algorithm like in QGW, I am not sure it is possible to maintain a reasonable FPS rate (see “crashtest” of QuickGeoGL:

Stephen says:

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.

Uwe says:

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?

Troy says:

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.

Commenting closed.

Get started today with Qt Download now