What I'm trying to achieve is something like this - that is, an OpenGL view contained in a standard window, alongside some buttons, menus, etc.
However, I'm trying to use non-managed C++ and WinAPI to accomplish that (project requirements), and, if possible, (free)GLUT.
However, it seems to me that the only thing possible using GLUT is to create a separate window. Am I right, or is there actually a way to pass a window handle to GLUT for rendering? Or am I completely off the track?
Yeah, as far as I am aware GLUT only lets you do full-blown windows and will not let you paint into an arbitrary rectangle. There are a number of tutorials on setting up a render context in Windows using nothing but the Win32 and WGL APIs. Once you get your context setup, you can effectively do everything the same way you would with GLUT, but use the appropriate WGL function for swapping buffers.
Here's a high-level overview of what would be involved, though it's really text-heavy and related to MFC it outlines the whole process. You should be able to lookup the appropriate WGL API reference to implement this.
There's really no point in using GLUT if you've already decided to use the Win32 API to be honest, it is going to try to hide everything from you including the message pump that you'll need to handle dialog initialization and button events. If your requirements weren't limited to Win32 API, I would suggest something a little more portable like Qt for a framework that's dialog-friendly and supports OpenGL.
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.
I have a general question on how to develop an image viewer plugin with Firebreath. For that, I would like to incorporate a GUI framework, like wxwidget or Qt. The GUI would be used to to fire up some dialogs, adding a toolbar on top, or to open context menus with right clicking an image.
As far as I understand I have a hwnd handle and so I can draw onto a window. I also understand that I have various events I can react on, like mouse button clicks or keyboard strokes. But it fails me how I would add graphical menus, buttons, etc. I know I could use html around the window but that's not the route I like to take.
For instance, does it makes sense to render an user interface offline (in memory) onto an image and then keep somehow track of the state internally?
Has anyone done such thing? Or can anyone give me some insight on how to accomplish adding a user interface.
Assuming you only care about windows and assuming that you don't mind using a windowed plugin, which is the easiest (but no HTML elements can float over the plugin), it should be no different than creating a GUI in any other windows application.
You are given a window that shows up with the AttachedEvent; when DetachedEvent is fired you need to stop using the window. Many people create a child window inside that parent window and use that for all their actual real code which makes it a little easier to use one of those other abstractions, but that's basically all there is to it. I don't know specifically how you'd do it with QT or wxwidget but you'd create a child window of that HWND that you are given and have the abstraction do your thing for you.
As to whether or not it would be rendering things offscreen, etc, I have no idea; that would totally depend on the window system. There is no reason that I know of that you would need to do that, and most things just draw directly to the HWND, but there are a zillion different ways you could do it. It looks to me like what you really need is to understand how drawing in Windows actually works.
I hope that helps
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.
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.