opengl & widgets


#1

yow all

I’ve been fiddling with a ‘content-creation-tool’, doing it from scratch. I’ve solved the user-interface in the same graphics as the ‘content’ (opengl, glew, glfw) , but it’s taking way too much attention away from the case of the matter. So, I’ve hooked code::blocks up with wxWidgets and look forward to find a solution this way.
I should probably have scrutinized the problem-set before I start popping questions, but, in my previous code I’ve already felt the limitations of how restrained I am on segregating the code. Some specific opengl-code cannot be delegated into libraries on their own.
The short question is, how do I fuse opengl & wxWidgets into one visual presentation? It would seem rational to put the opengl into it’s own panel. Is it doable?
An alternative solution could be to generate the opengl in it’s own context/window and somehow bind it to an ‘independant’ gui in another window.
A second slimmer alternative would be to call widget-popUps within the opengl-context.
Shall I expect to learn something about ‘threading’ to make it work? … I figure that both contexts want a main-thread?

Cheers


#2

The short question is, how do I fuse opengl & wxWidgets into one visual presentation? It would seem rational to put the opengl into it’s own panel. Is it doable?

wxWidgets has its own OpenGL widget for rendering that you can attach to any other widget of your program. You can create your own widget that derives from it and put all your OpenGl related code/classes inside. In this case you won’t need [STRIKE]GLEW[/STRIKE](EDIT: GLFW - typo wich could cause a lot of confusion). All the stuff previously handled by GLFW must be transferred to the corresponding wxWidgets functions.

Shall I expect to learn something about 'threading' to make it work? .. I figure that both contexts want a main-thread?

I am not 100% sure what your specific needs are. If you mean that wxWidgets is started by calling a fancy function/macro (I forgot the name) that only returns if you exit your program and your rendering needs a infinite while loop to continuously update your OpenGl output, than the answer is no, you don’t need to know about multi-threading. wxWidgets has a Timer class (wxTimer?). All the things you usually do in the while loop is copied to the timers onTick event callback function.

You could also test QT instead of wxWidgets. It has a nice IDE QTCreator which supports drag and drop GUI creation.


#3

If you’re using wxWidgets, it replaces GLFW. For OpenGL rendering, use a wxGLCanvas widget in conjunction with wxGLContext (GLFW implicitly creates a context for each window and manages it automatically; wxWidgets used to do this but later versions require the application to create and manage the context).


#4

hi X & Clements
Thanks for your input.
I had a look at the wxContext and wxCanvas … at a first glance there are preciously few accessible members in those classes. My assumption is, that wxWidgets uses an ‘ordinary’ opengl-context for it’s generel visual presentation … there again, I’ll have to overwrite/deal with this inner opengl-context before switching to the context that draws my contents. This assumption may be wrong. … ooo the source-code is present. That would be the proper place to look at the classes.
As said, I’m a little early out. My wxWidgets-installation may be slightly off (showing a lot of deprecation-warnings) and I havn’t yet experienced with with the samples.


#5

wxGLCanvas inherits from wxWindow; the documentation for wxGLCanvas only lists for the methods which are added (i.e. the constructors, SetCurrent() and SwapBuffers()). Layout and event handling are the same as for other (non-OpenGL) widgets.

Other widgets don’t use OpenGL for rendering; they use the platform’s native rendering API (e.g. GDI on Windows) or the underlying toolkit (e.g. GDK on Linux).


#6

I just postetd a very short but working source at wxWidgets-forum: https://forums.wxwidgets.org/viewtopic.php?f=1&t=45520&p=188844#p188844