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.
Related
I was looking at how sometimes when you right click, the menu goes outside of the window.
Is this implemented with a separate window? If so, how can I get this functionality. I am trying to use GLFW, but I understand if it isn't possible.
Currently I am on windows, but I like keeping my options open, which is why GLFW would be preferable.
I noticed that GLUT has such a feature. If you are confused to what I am looking at then look at that.
Thanks for any help!!
Overlapping menus (in MS Windows) have to be implemented as a new top-level window, you would have a new OpenGL rendering context and draw the menu in that space - yes, it's a fair bit of work all for the edge-case of a menu overspilling the parent window,
However this isn't often a problem in OpenGL programming because if you're working on a full-screen game then the menu will always be displayed within the main window, and even if it isn't a full-screen a game your users really won't notice them as games tend to use different UI concepts like radial-menus which wouldn't overspill the parent window.
Or if you're working on a non-game title, chances are it isn't full-screen and is going to be an OpenGL rendering area within a larger application that is rendered using a native UI toolkit (e.g. 3ds Max, AutoCAD, etc), in which case no problem: just use native menus.
You can, of course, use native menus in an OpenGL application anyway, provided you do the necessary plumbing for native window messages.
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.
I'm making this fingertip-driven app ( OpenCV 2.3.2 + Qt 4.7 being developed in Visual Studio 2010 ) in which I'd like to utilize Qt's GUI especially its dialogs. The fingertip's position will be detected and tracked through VideoCapture. Imagine Microsoft Windows' Paint being used with one fingertip. I've been speculating about the following options:
subclassing QEvent and installing an eventFilter to the widget to filter out unnecessary events
subclassing QCursor if mouse events are dependent on cursor positions
making my own color picker and other input dialogs which doesn't subclass any of Qt's specialized dialogs, which is what I'd probably end up doing if none of the above are feasible. I looked into QColorDialog's source code and found QColorWell and QColorLuminancePicker and am now thinking of the least tedious way to similar widgets.
What could be the most practical and the least computationally intensive way to do this? Sorry if my English wasn't clear or confusing. Thanks in advance.
You can simulate this behavior by implementing QTouchEvent and calling that event simultaneously by your possible image processing thread. You just need to generate parameters needed by QTouchEvent (touch points, locations etc) by your image processing algorithm.
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've been programming opengl using glut as my window handler, lately i've been thinking if there are any advantages to switching to an alternate window handler such as wxWidgets or qt.
Are there any major differences at all or is it just a matter of taste? Since glut provides some additional functions for opengl-programming beyond the window handling features, would there be a point in combining an additional toolkit with glut?
I can only speak from experiential of using QT:
Once you have the basic structure set up then it is a simple case of doing what you have always done: for example, the project I am working on at the moment has an open gl widget embedded in the window.
This widget has functions such as initializeGL, resize...paintGL etc. Advantages include the ability to pass variables to an from the other windows / widgets etc. QT also has additional functions for handelling mouse clicks and stuff (great for 2d stuff, 32d stuff requires some more complex maths)
You need to move from glut as soon as you want more complex controls and dialogs etc.
QT has an excellent openGL widget there is also an interesting article in the newsletter about drawing controls ontop of GL to give cool WPF style effects.
wxWidgets also comes with an opengl example but I don't have much experience of it.
Well - glut is okay to get a prototype going.
It depends on the OS, but later on you may want to prevent the screen-saver from starting, you may want to disable the task switch (only the bad guys do this though), You may want to react to power down events. You may find out that glut can't deal with dead-keys on one or another operation system, or, or, or... There are thousand reasons why you may want to get rid of it.
It's a framework designed to make the start easy and do 90% of the usual stuff you need, but it can never do 100%. You can always hack yourself into glut or lift the init-code, but one day you will find out that it's easier to redesign the init-code from scratch and adjust it to your task.
Opening a window and initializing OpenGL is not rocket-science . Use glut as long as it works for you, but as soon as it makes problems get rid of it. It'll take you just a hand full of hours, so you won't loose much.
For a toy project glut is the way to go though.
SDL, while not just a window handler, will make it easier to use OpenGL than raw Win32 code. However, my experience with Qt, GTK and wxWidgets has not been too bad... certainly not that much better than Win32, its probably a matter of taste in those cases.
I'd recommend avoiding widgets and wrappers like GLUT if you want a fine level of control over the window and resources, but if you are just looking for speed of development then these tools are ideal.