I need a cross-platform GUI toolkit with OpenGL support. I also need to be able to draw on a canvas or panel from an image buffer. The candidates I've chosen so far are FLTK (it can do OpenGL windows -- I don't know about canvases), Qt, and wxWidgets.
Any idea which would be the best?
Thanks!
I would say Qt. But that might be argumentative question...
Hey Deep, XVT support openGL. It's a GUI cross-platform toolkit for C and C++ www.xvt.com
For simple things I would suggest GLUT or something similar. But for anything above a simple window into which you render some OpenGL, I strongly recommend Qt. But as tibur said, its probably a matter of taste.
Checkout the Ecere SDK. It's a feature rich cross-platform GUI toolkit, and it supports a variety of graphics driver (e.g. GDI, X11, OpenGL, Direct3D). It has a built-in 3D engine, but you can mix it with your own OpenGL code as well, there are samples showing you how to do just that. It was originally designed as a GUI system for in-game menus, so it supports full screen mdoe as well as windowed mode, but is now a general purpose SDK.
Related
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.
Glut seems rather old, and SDL also as if it's not the youngest anymore - what is being used as (cross-platform) window manager for OpenGL nowadays?
Cross platform UI toolkit
1. wxwidgets
2. fltk
3. qt
4. glut(freeglut)
5. sdl
I have used glui. Sucks real bad(in terms of performance). There huge difference in performance penalty just by including glui(without actually using it) in your apps.
To be honest, i prefer platform specific UI toolkit. Faster. Reliable.
Depends on how you want to use it. Don't think there is a clear winner.
I like to use Qt because I'm familiar with it so it feels easy to me, and because I use it for other UI elements in my mostly windowed openGL apps.
Haven't tried it myself, yet, but want to in my next project. It seems to be very popular.
SFML . It`s the "successor" to SDL written in C++
I am using freeglut, but it is just a bit improved glut.
You can also use QT
I think GLFW is the best choice for small to medium applications/games. This type of libraries should be easy,small and fast with no extra services such as image helper functions and so on. GLFW is going to remove all helper functions to focus on the main goal.
QT is the best for graphics applications but not for games or small applications.
Besides Qt, GTK, wxWidgets... What are the recommendations for a cross platform, open source GUI framework library that works with OpenGL?
Its not quite a GUI framework. But GLFW is good for an OpenGL window with some extra features like keyboard and joystick handling.
I found the other framework I was looking for. It is SFML. I only used it briefly but I do remember liking it very much. It does contain a lot of nice extras going a step further than GLFW. If I recall correctly the documentation was stellar.
For a full featured cross-platform GUI framework I think you would be hard pressed to beat QT, GTK, or wx.
I'm not sure, but at a guess, the other framework mfperzel was trying to think of might have been fltk (the "fast light tool kit"). Where glfw is mostly an OpenGL window with some ability to read the mouse and keyboard, fltk is a GUI framework that supports OpenGL (but as the name implies it's still quite a bit smaller and faster than most GUI frameworks). I haven't tried it yet, but there's a new GUI builder program for it (FLUID) that looks fairly promising as well. One warning though: FLTK uses its own widgets, which tend to look at least a little foreign to most users.
I want to add joystick support into an openGL application.
Is there any class that can help me?
Thanks in advance.
OpenGL is a graphics API. It has no notion of input devices.
Need more info for a better answer such as platform. On Windows there are many options for handling input. Depending on what you want to do that is. Google for more info. But a start would be simple input handling via the Win32 API. This all presumes you use Windows of course.
OpenGL does not provide direct access to the joystick as it is only a graphics library.
For joystick support we will need to know what platform you are targeting.
For example, on Windows you would likely use DirectInput.
Some GLUT implementations have: glutJoystickFunc
As mentioned in other answers, OpenGL is only a graphics rendering API. It doesn't even know how to open a window, not to mention how to handle mouse or keyboard input; something else must do it for it.
If you want a cross-platform I/O wrapper for OpenGL which also provides joystick support, take a look at SDL - Simple DirectMedia Layer. It may scare you at first, but it's still easier than writing I/O and windowing stuff for a single platform, not to mention writing a wrapper for each platform out there (SDL covers many of them).
So, take a look at SDL.
I'm searching for a OpenGL User Interface Library like WxWidgets but not OS dependent.
It would have to provide callbacks for user input since this is OS dependent.
If something like this doesn't yet exist (which I doubt because most games have most of the Basic UI Elements) is there a OpenGL HTML/CSS renderer?
FLTK, GTK+, and QT support OpenGL widgets in a portable way. QT in particular can render all of its widgets in an OpenGL viewport. I know there's been some work on getting GTK to do the same thing, but I haven't heard on the progress of it.
OTK comes up on a quick Google search as an OpenGL-backed widget library.
It's also worth pointing out that Cairo has an OpenGL backend, and there are a number of toolkits that depend on it, including GTK+.