When I browsed the source code of Qt I didn't find how it actually draws a GUI component, but I know it uses OpenGL.
I want to know how does a GUI library like Qt draw its GUI components (ex : QPushButton ,QWidget)?
Can any one help me with a basic idea ?
In Qt-project site :
Qt is painting QtWidgets using QPainter, which uses (usually) the raster engine to draw the content. It is not using native OS calls, apart from few exceptions (file dialog, for example, which can be drawn either natively or using QtWidgets).
QtQuick is painted using scenegraph, so OpenGL. Also, no native OS calls here.
I think you either misunderstood (there are several meanings of the word “native” in computing) the stackoverflow post, or your information source is wrong.
OK, then to be clear: by “native” I’ve meant using native OS controlls, like wxWidgets library does: asking the OS to draw native scroll bar, or combo box, etc. Qt does not do this. It paints all the widgets itself, and only tries to mimick the looks of the OS it is running on.
But obviously, some kind of native OS calling is happening deep inside, in order to actually draw some pixels on the screen, and open native window container. But that is usually not important at all to high level UI developers.
You have a clear choice whether the widget should be drawn by the CPU or the GPU: widgets can use different painting methods (native, raster, OpenGL, for more see here! [qt-project.org]), and the user has choice which one should be utilised. Most people do not use that, though, because the default settings work well.
Thanks.
Related
I inspected the Qt GUI interfaces using window spy tools and I know that it does not use windows common controls or any custom window class to create its UI elements and animation effects. I asked before here about developing a custom GUI framework using GDI/GDI+ but most people responded against these technologies, so the question remains which graphics technology Qt or any other equivalent appropriator system uses to render their UI?
I am aware of DirectX/OpenGL but isn't it overkill for simple requirements? If the answer is going to be one of the above then again I wonder how one could implement robust font rendering and vector graphics solutions with these polygon rendering technology? the full featured text editor is another huge challenge.
Also there already exists solutions based on directx/opengl like MyGUI and CEGUI but I think they look ugly and nowhere near how Qt looks.
First things first, Qt-5 introduced a new rendering model, which can (but is not required to) use OpenGL for rendering the UI elements. The upshot of this is, that one can truly mix custom OpenGL rendering with Qt widgets. The downside is, that some kind of OpenGL support is required, which not all systems have.
So Qt also has these two other drawing systems: Native, which will use the hosts systems native graphics primitives (GDI, CoreGraphics, X11/XRender) and raster which does a complete rasterization of a whole window into pixel buffers, where then only those are blitted over to the underlying graphics system. raster is the slowest of the graphics backends, but it gives consistent results for all plattforms and target systems. Hence raster is usually used for programs where consistent appearance is strictly required.
I'm trying to develop a cross platform (or at least desktop + embedded hardware) application. I would like to use Qt Quick to create a touch friendly GUI. I have been implemented a classical application with a QGLWidget displaying data. It is important that only a part of the window is in OpenGL. Because of this there are problems with EGLFS and LinuxFB. Only X11 (or maybe Wayland) can display the application properly (others generates a couple of errors about missing setParent function and the whole screen is black). Now I'm trying to achieve the same thing in QML. I want to use this OpenGL renderer as part of my QML application and some Qt Quick widgets around it. I found a couple of people asking about the same thing and the answer is always to subclass QDeclarativeItem and call the painter's beginNativePainting() (the others says to export it through QDeclarativeItem, but I cannot figure out how to do this). The problem is that on desktop, Qt 5.11 the native painter is not OpenGL. And in QT5 there is no way to force OpenGL graphics system. So when I try to get the OpenGL context (QGLContext::currentContext()) I always get NULL. Another problem: If I export my widget with qmlRegisterType("Test", 1, 0, "Test"); it becomes only visible when I use QDeclarativeView, but then it doesn't sees Qt Quick. If I use QQuickView it says module "Test" is not installed. How can I implement this properly?
QDeclarativeItem is from Qt Quick 1 and Qt4. With Qt 5 and Qt Quick 2 you should use QQuickItem.
There is at least 1 example of this provided with qt docs, which you can find in Qt Creator in the Welcome tab in the Examples section.
I'm thinking of a library that would render all custom controls to a bitmap, so the final "gui image" could be applied to a windows form, osx window, or OpenGL texture, etc. Does this exist? I know the other libraries like QT are intermediates that finally use the OS specific control code. I want something that is completely independent of the OS code, and is just layering the custom control graphics onto a final image in memory. I'm thinking this would be the ultimate X-platform GUI library for C++. Thoughts?
PS: I know questions asking for opinions are not really kosher but I googled hard and couldn't find anything. I need some input here.
Thanks!
EDIT: Ok, to clarify that I meant GUI library, I meant the library is given mouse/keyboard events then handles the logic of the typical GUI chain, then it's final render target is a bitmap in memory that I can do stuff with after. It would be GUI library, not just a canvas.
I guess this question has been ask before, but I have not found sufficient answer to even start poking around. Most answer refers to catching WM_PAINT method directly and do custom rendering, or use a onwer draw object. However, I did not see a centralized place that has the info. to start researching. Hence, the question.
My goal is to create a very simple GUI program with custom look into it. I prefer the way winamp does their custom look that is customizable through "skins". However, I am not interested in using some cross-platform library like GTK+, QT or wxWidget.
I have some experience in system programming, but not much for GUI. I spent most of my time developing console applications, and I just started doing some QT development. If you can point me in the right direction, I'd be very appreciated.
PS: I am interested in both windows and linux environment.
Everybody,
Sorry for the late reply. I had a chance to have a quick talk with the original developer for winamp, and this is the quick answers I have:
Using skins: Artists create skins, developer will render the skins
To the OS (Windows), winamp is just one pretty box, nothing else. There is a container windows, and that's about it
All controls (button, label, list, etc) are implemented by winamp team themselves. All messages and stuffs are passed as relative position to the container window. WinAmp and the GUI engine has to decide if a button is clicked or if the label next to it is the target, etc.
Rendering artists skins created in XML
I do not have the details on if they use any libraries to do all that, but I am suspecting they do hook a window call directly, and do custom rendering themselves.
GUI skin usually using plug-in mechanism
I guess this is exactly what you are looking for:
https://www.linux.com/learn/tutorials/428800:weekend-project-creating-qt-interfaces-with-gimp?utm_medium=twitter&utm_source=twitterfeed
I also interested in creating custom look of window and widgets.
Speaking about widgets it's not hard, just need to create subclass (if you are using C++) or some widget and implement some methods like draw, handle etc. But this solution is good only if you use some high-level library like GTK, QT, etc. If you want to implement all controls by your own, you may get any graphics library, which can create window and do any graphics inside. For example, SDL2 + Cairo. SDL2 for creating window, Cairo for vector rendering controls/widgets. Both of this libraries are for win and linux. Another option is take opengl/vulkan + some lib for rendering window. It could be SDL2, SFML, GLFW.
If you really interested how it works on low level, then search Windows API for Windows and XLib or XCB for Linux/X.Org.
Speaking about window, I still investigate it. However I have one thought: you may create an empty window and then draw whatever you want. Then you need to add handlers for resizing window on the borders. But I am not sure if it's good solution, and if it won't freezes.
I am writing a program in OpenGL and I need some sort of interfacing toolbar. My initial reactions were to use a GUI, then further investigation into C++ I realized that GUI's are dependent on the OS you are using (I am on Windows). Therefore, I decided to use QT to help me.
My Question is if I am taking the best/appropriate approach to this solution. Am I even able to write my OpenGL program and have the GUI I want to create interface with the C++ code to do what I want it to do.
For example, If I create a simple "control panel" with arrows in each direction. And on screen I have a box object created by glut can I interface the arrows to be clicked on and interact with the openGL program to move the box?
Using Qt is coherent for your problem: it provides good integration of OpenGl through the QtOpenGL module.
Derive your display classes from QGLWidget (until Qt 4.8) or from QOpenGLWidget (since Qt 5.4) and implement virtual methods paintGL() etc.
You will have access to the Qt's signal and slot system so that you will be able to catch Gui events and update the OpenGl display.
You can use regular non-OpenGL Qt widgets on top of a QGLWidget so what you describe is do-able.
One thing I came across when doing this was that the regular widgets had to be opaque. The moment they were transparent in any way there was all sorts of garbage underneath them. That was a while ago so maybe the latest version addresses this issue. May have been platform-specific too so YMMV.
Stay in GLUT. There's no need to add Qt for a control panel. You could open a sub window (or second window, whichever works better for your program design), and draw the controls into that window, and use GLUT to handle the mouse interaction.
Furthermore, Qt and GLUT each have their own event loops. To use just Qt's event loop, you'd have to abandon much of the GLUT structure, since the GLUT event loop would not be there to call your callback functions. Qt does have the functionality to have let somebody else event loop call Qt's event processing code, but I don't think there's an easy way to make GLUT hand off the event information.