I'm writing right now an application in Python (PyQt / PySide), which should visualise and should give the possibility to edit complex dataflow graphs (like nodes in blender). Additional I want these nodes to display opengl 3D objects (small opengl scenes, like buttons on nodes), images, controls etc.
The GUI will be complex also - it will allow to subdivide to panels and allow in each panel to open a context (like in Eclipse or Visual Studio).
I'm learning QtQuick 2.0 right now and I've read Overview of painting in Qt 5. I'm wondering what are the real benefits of using QtQuick over QPainter.
QtQucik 2.0 no longer uses QGraphicsView as its backend (it uses directly the OpenGL context)
In each technology you can use OpenGL. In each you can draw custom looking buttons and widgets (like nodes, their connections etc) (you can draw them even with QPainter and handle mouse by yourself).
Of course the qml is declarative and can optimize the OpenGL calls, but does it really matter? I've been searching very long for any benchamrks between QPainter (QGraphicsView) and QtQuick 2.0 but found nothing interesting.
So the questions are:
Is really QtQuick the technology "of the future"? Should I use it if it is possible? Will I benefit from it in the future? Or it is simple "another" way of doing the same things like with QPainter with QGraphicsView and QWidgets?
Are the possibilities of QtQuick 2.0 really higher than the PySide / PyQt?
Is the QtQuick more suitable to develop this kind of application or should I stick to PySide / PyQT and QPainter?
The OpenGL mostly matters if you want to embed the UI directly with other OpenGL elements, and especially when you want smooth transitions, animations etc. on limited hardware.
1), 2) are hard to answer - it depends. For a desktop application with complex eclipse-like UI doing everything in QtQuick isn't really feasible. I'd stay with widgets there. Reimplementing Eclipse in QtQuick would be a huge task and would end up in a hardly usable UI that doesn't blend in well with the desktop. If you want animated, custom UI, then I'd go QtQuick. There it's the right tool for the job and mimicking it in QWidget/plain QGraphicsView would be pain.
A1. QtQuick is a modern technology to implementing fluidly advanced UI. It uses Scene Graph as backend which is newest technology to utilising Hardware Acceleration in a high performance and very intelligent approach. Scene Graph has best performance between QPainter, QGraphicsView, Scene Graph if target machine is OpenGL ES 2 capable.
It is very productive but you need to be care about some performance tips to keep performance as high as possible.
It is naturally suitable for MVC/MVC-like patterns but choosing/designing an efficient and suitable model to integrating and interaction between Model/Controller/View needs experience).
A2. Your question is wrong! QtQuick is part of Qt not a new thing parallel to whole Qt.
A3. In my experience, in case of a big and complex applications, you need to be careful about choosing a good approach to integrating C++ and QML (in other words controlling UI from C++).
Also you can create custom elements using QPainter or QGraphicView or QOpenGL or QQuickItem and integrate it with QtQuick based UI.
Keep in mind that static build of QtQuick is not possible now! (AFAIK)
Last word, I suggest you strongly to learn and test it in real world. Because it grows rapidly in Qt Framework and it is the future in my opinion.
Related
the QT widget is very time consuming in terms of UI development, my CSS sheets has 3000 lines of code already and it is very time consuming to do UI changes. My application is very demanding in terms of performance, I was thinking of embedding the widgets into QML to have easier and faster control of the UI but I'm really worried about performance, will worth the try or it is just bad practice?
My application is very demanding in terms of performance, I was
thinking of embedding the widgets into QML to have easier and faster
control of the UI but I'm really worried about performance, will worth
the try or it is just bad practice?
Since Qt 5.1 we can easily embed QML view to Qt Widget container. There is a blog I stumbled upon some time ago: Combining Qt Widgets and QML with QWidget::createWindowContainer().
As for performance, unsure what kind of performance is in demand for your application? Overall QML renders to screen via OpenGL or very fast. On the other hand with QML you often need to deal with JavaScript which of course is not comparable to C++. There is Qt Quick Compiler introduced to commercial Qt, though.
As for QWidget-based UI vs. QML: the discussion can be considered an expression of opinion etc. Some consideration points then:
Developing and maintaining one kind of UI, either widget or QML based is easier.
Hybrid UI is possible but it makes sense to understand what you can gain from it.
Most desktop apps are fully satisfied with widgets only.
When the app supposed to be ported to mobile platforms as well then QML makes more sense.
When the app supposed to rely on 'touch' then QML is also more beneficial than widgets.
the QT widget is very time consuming in terms of UI development, my
CSS sheets has 3000 lines of code already and it is very time
consuming to do UI changes.
Hmm... very heavily styled widget-based app? I can only be sure that these two concepts: widgets and QML are very different but both widget stylesheets and QML are declarative language though different. I am also sure that any serious app needs more of C++ and with QML we need to spend time bridging C++ code with QML.
And the distribution of QML apps can also be a bit more complex than purely widget-based: for instance you need to customized Qt build to support OpenGL emulated for certain VMs and platforms: that is one interesting topic. Also with Qt Quick widgets you use should put them either to resource distributed with the app or you need Qt Quick Compiler. And if you use it, be sure that all QML code was compiled by it and no part of the app still uses 'scripted' QML which is missing from resources. I made use of Qt 5.5 Quick Compiler in our app and found not only quite a few bugs with it but also still needs to drag certain Qt Quick files from framework together with the app install package. That is not as bad with standard dynamic link and windeployqt tool. But a serious app often needs to be statically linked with all its dependencies and then we cannot use windeployqt tool.
Overall Qt is departing from widgets to QML but what can we gain and how much we need QML in our real applications is a long discussion.
According to this article, there are two main methods for rendering raw OpenGL into an application whose UI is otherwise managed by QtQuick's scene graph. In short, they are (according to my understanding):
Calling raw OpenGL methods in hand-written code that is hooked into the scene graph's render loop through some APIs exposed by QtQuick.
Rendering the raw OpenGL portion of your scene to a QQuickFramebufferObject, which is treated like a component in the scene graph and itself rendered as if it were a texture.
What are the advantages/disadvantages of the two approaches?
The issue with QQuickWindow::beforeRendering() or QQuickWindow::afterRendering() signals is that all OpenGL drawing done from their slots will be appropriately under or over the rendered Qt Quick scene. If this is good enough for you — ie. you only want to draw a custom OpenGL background or some kind of overlay — then go for it.
If you need more, ie. use OpenGL to render some QtQuick Item that placed within the scene graph, then you have to go with the second option: rendering OpenGL to a framebufferobject that is used as a texture on some QtQuick Item.
As the documentation article you have linked to states, it gives you more possibilities (using multiple rendering contexts or even multiple rendering threads) but also comes with performance cost. It is also more troublesome to implement.
Generally, as the option 1) is usually inadequate, you are forced to go with 2). It is the only way to use raw OpenGL within a QtQuick scene that I know of.
I have an wizard application written in C++/MFC that I want to improve the UI. Different buttons, change the dialog background color, etc. Could I use QT to improve the appearance or should I change to WPF and C#?
Qt 5 gives you essentially five (5!) UI toolkits:
The Gui module that is similar to what you got with a very good 2D graphics library in the late 1980s/early 1990s. You have access to the buffer of the window and to key/mouse events. Everything else is up to you. This would be the fastest way to port an existing application from "back then". The graphical primitives are neat, with fonts, painter paths, gradients, etc. but there's no notion of a widget, only of a top-level window. You draw everything where you want it to be within that window.
The provided concepts are at a higher level of abstraction than typical platform toolkits like winapi or xlib. In terms of graphical primitives it is more akin in spirit to Cairo or PDF.
It is possible to parallelize the painting of a QRasterWindow in the same way as it is done for QWidget.
The Widgets module gives you Qt4-style widgets and layouts, with customize-able styles. This is the model perhaps most like MFC, although it has much more functionality. The widgets are so-called alien widgets - it means they don't have native window handles. This keeps things fast. You have a multitude of pre-written widgets to do user input/output of all kinds. It is possible to parallelize the painting of a widget..
The Declarative module, a.k.a. Qt Quick 1, uses the QGraphicsView widget from the widgets module to display a graphical scene. This scene is described using QML. The controls are fairly rudimentary and there's no platform-specific styling. It will look all the same no matter where you run it. There is good support for animations/fluidity in the interface.
The Quick module, a.k.a. Qt Quick 2, uses a new OpenGL ES-based scene graph and can run on top of either a widget from the widgets module, or a raw window from the gui module. The scene is described using QML. There is a desktop components set that gives you platform-styled controls like combo boxes, text inputs, tables, etc. The new scene graph can really leverage the hardware and will outperform both widgets and Qt Quick 1 when you have heavy animated UIs. This is the way to go for the future. Qt 5.2 brings in an entirely new Javascript engine and a new scene graph renderer, with even better performance. Qt 5.11 brings in a new Javascript engine again, twice as fast.
The 3D module, exposed both via C++ and QML APIs, is a high-level 3D object and scene rendering system, tailored for interactive applications. It makes it easy to implement user interaction with 3D objects. The C++ and QML APIs are peers and can be used per your preference - this is in contrast to Qt Quick, where the only the QML API offers the full functionality.
Both Qt Quick 1 and Qt Quick 2 can wrap existing widgets at very modest performance cost, but you do lose out on some of the niceties of "native" QML objects.
Do note that there's a separation between the need for an OpenGL implementation and there being one provided on your system. On post-Windows-XP systems (Vista, 7, 8, etc.) you should normally use Qt 5 with its own ANGLE implementation of OpenGL ES 2 that runs on top of DirectX. Only on Windows XP you're forced to use the system OpenGL drivers.
Qt is a generally very nice framework to work with even for non-gui applications. It has good cross-platform abstractions of networking and file I/O, time/date, and provides a bunch of other general-purpose goodies. It is relatively easy to use it alongside ncurses, for example.
The fastest way to port existing MFC code would be to stay with C++ and use Qt with the qtwinmigrate solution. The latter is a BSD-licensed shim layer that can get you up and running very quickly.
I've just started learning Qt recently, finding QML quite interesting for implementing UI component. Before the project really kick off, I've got some questions:
For a fresh start project, should I just use QML? Does QML be designed for replacing QWidget?)
If I go with QML, is there anything else must be implemented with C++? Or better implemented with C++ for better performance? (I know some customized UI components can be integrated through plugin) What's the relationship between QML and C++ widget?
As for performance or rendering issue, does QML better than native C++ widget?
When you start a question with 'Should I use', it is quite a good hint that SO might not be the right place to ask it. Even more when there are only answers, which start with 'It depends on...'.
QML is not designed to replace QWidget. It is a different technique. Which one to use, depends on your requirements.
Whether or not you must implement additional stuff in C++ depends on your project. Some things are easier in C++, others in QML. And some stuff is not possible in QML at all.
There is no relationship between QML and C++ widgets.
And the performance of QML is in most cases more than sufficient. In almost every case QML is used to create user interfaces. I doubt that there are many cases where clicking a button or opening a dropbox folder is performance critical.
I had a chance to put this question to a few Qt experts at the World Summit today and the general take was that because QML component rendering can be done through hardware acceleration that it is preferred for apps requiring high performance graphics, eg automotive dashboards. OTOH widgets seem to be used for desktop applications. Another consideration is that while widgets can be styled using Qss (Qt's version of Css), QML components cannot.
In QML based applications computationally intensive functions are generally written in C++.
HTH,
Eric G
I have been looking far and wide to find out how, if it’s possible, you can fill a particular area in a QML screen with an OpenGL context and do custom OpenGL only in that context. I’ve seen plenty of demos where the QML components like buttons, etc lay on top or below a screen-wide OpenGL context (as is typically required by games), but I’d like to be able to situate several distinct OpenGL contexts within QML and have the QML file define how large they are, where they are positioned, etc.
Now, since Qt 5 is all OpenGL under the hood, it makes me wonder if using a Canvas element with custom drawing via javascript could result in similar rendering performance as custom OpenGL? This would be a meaningful alternative but it’s not clear to me how the javascript drawing is handled via runtime compared to custom OpenGL drawing.
What is it that you want to draw? QQuickPaintedItem may be the simplest way to go about it. When you're using QOpenGLFramebufferObject as the target, the painter will use OpenGL to paint the texture. It might be easier than writing your own OpenGL code if all you're doing is 2D.