Slashdot Mirror
GTK+ Developers Call For Help To Finish Cross-Platform OpenGL Support
jones_supa writes OpenGL support under GTK is getting into good shape for providing a nice, out-of-the-box experience by default on key platforms for the GTK+ 3.16 / GNOME 3.16 release in March. For a few weeks now within mainline GTK+ has been native OpenGL support and as part of that a new GtkGLArea widget for allowing OpenGL drawing within GTK applications. Since that initial work landed, there's been more GTK+ OpenGL code progressing that right now primarily benefits Linux X11 and Wayland users. While good progress is being made and improvements still ongoing to the GNOME toolkit, GNOME developers are requesting help in ensuring other GTK+ backends can benefit from this OpenGL support. If you are using or planning to use GTK+ 3 on Windows or OS X, and you know how to use OpenGL on those two platforms, please consider helping out the GTK+ developers by implementing the GdkGLContext API using WGL and AppleGL.
Its good to have choice. If there is none, things like heartbleed or winshock can happen.
Would love to, but I'm busy writing a combined init system, web server & tic-tac-toe engine.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. http://www.gtk.org/
9/11: Never forget it was a false-flag operation
GTK+ used to be a general purpose toolkit and it was originally named the GIMP Toolkit. The gtk+ homepage still refers to it as such. It is, in theory, not only for GNOME. The sad reality, though, is that these days the GNOME developers are busy removing features from GTK+ which breaks existing applications, cripples them and removes features from them so in practice it's basically a GNOME toolkit as of right now. That does not mean you can't submit patches to it in order to make it more general-purpose. If this is worth your time is, as you indicate, an open question, though. Like .. what is the point of submitting a patch like "This patch reverts your removal of icons from menu items and puts the icons back in the menus"? I could go on but you get the idea. Many of us have simply decided to stop using GTK+ for development because of their various unacceptable choices and see no point in contributing to this project which has sadly left only GNOME developers to work on it.
9/11: Never forget it was a false-flag operation
WGL and AGL are the Windows and Apple (respectively) are the glue APIs that allow you to setup and work with an OpenGL context and surfaces.
You can't render OpenGL commands using the native drivers without first setting up an OpenGL context with these APIs.
The ignorance here is that you know so little about programming, and OpenGL in particular that you don't realize that AS PART OF THE SPECIFICATION, EVERY OS HAS THESE LAYERS between native windowing system and platform independent OpenGL API.
For X11, you might have heard of ... glx ... Which is the equivelent.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Why would someone back the Qt stuff instead of GTK?
Let's face it. Some of us prefer GTK over Qt. Get over yourself and your One True Way, Holier Than Thou attitude. You're free to do it how you like, and I'm free to use what I like. Choice is good. And in this instance, it was appropriate.
Need I point out that QT has had cross platform OpenGL support for many years? In QT, this is mature, reliable, well integrated and easy to use.
When all you have is a hammer, every problem starts to look like a thumb.
I fully agree. I like the GTK+ API and I still continue to use it because shifting to another toolkit for my apps would be costly. But I'm loosing patience:
GTK+ development has become an unprofessional mess. Functions get deprecated even with minor version changes: you develop your app with version 3.xx and distribute it. Then people move to 3.yy (where yy>xx) and bang your app does not work anymore because someone decided to *remove* a function from GTK+ without any consideration for existing apps out there. Sometimes the fix involves a new function that does not exist in the previous version of the library, so you can't even find a real fix that would work with all versions from 3.xx and above. You just add some ugly preprocessor macros in your code to deal with different versions of GTK+ at source level...
An API is not removed just because it's deprecated. It just means that you are discouraged to use that function in new code, and that it *might* be removed in a later version. This is not uncommon in minor versions and you typically wait for a major version until you actually remove them, to preserve ABI compaitibility.
Difficult to say, it really depends upon the project, language and portability requirements.
Most of my projects are currently in C++ and/or Python. Qt 4.x and 5.x work well here for both on all current platforms (FreeBSD, Linux, MacOSX, Windows) including OpenGL support for all.
GTK+ 3.x is a non-starter. Its repeated breakage and dropping of functionality make it unsuitable for non-GNOME work (and even for GNOME developers it must be painful, as several of them have commented).
GTK+ 2.x might be a possibility for FreeBSD/Linux-only projects or projects where a subset of GTK+ which works on all needed platforms is actually functional. For anything complex, the chance of cross-platform breakage approaches certainty in my experience.
The GTKmm bindings are excellent but you are still wrapping a C API which introduces constraints e.g. for exceptions and I have run into bugs in the past; this is what the API should have been if C++ had been used from the start. I'd certainly be happy if they dropped the C implementation and made it the base implementation; it would resolve many of the quality issues with the library which are rooted in the inadequacy of OO-C compared with a proper OO language.
FLTK is superficially nice but its odd structure makes making new or derived widgets painful (from memory, not used recently). Certainly a possibility for simpler projects which don't need custom widgets.
wxWidgets is good in concept but fails in execution (it looks out of place on all platforms), and has to be a lowest common denominator in order to work with platform-specific toolkits. My trials showed up lots of widget layout issues if you wanted it to be good on all platforms, but with effort you might be able to make it work better.
GNUStep is a bit too niche for me to have tried using it in anger; last time I looked a decade back it was not completely compatible with the modern MacOS X evolution of OpenSTEP and required use of Objective-C. I wasn't sure it wasn't an evolutionary dead end at the time, and I'm not sure now.
Tk seems like a nice toolkit which has kept going over time and which does seem to work on all major platforms without too many major headaches. I'd certainly consider it if using a compatible language and didn't need the heavyweight widget and other libraries from Qt.
So I think very broadly I'd go with Qt > Tk > FLTK > GTK+2, though which would be most appropriate would depend upon the project.
Regards,
Roger