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
Started on this last night, but I'm not super familiar with the OpenGL details on OS X either. Help with scaling and fixing the painting welcome. https://bugzilla.gnome.org/sho...
Chu vi parolas Vikipedion?
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
No thanks.
These days: Redhat == Microsoft.
I am surprised that more people don't see that.
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.
How about 23? Look at the gallery for just a sampling.
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.
There is no such thing as "AppleGL". There is AppKit which contains classes to set up the OpenGL contexts and surfaces and GLKit for constructing textures, etc.
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.
The "Name 2" was to "That's not to mention that a lot of people do like Gnome3, but those who don't tend to not acknowledge that they exist." It wasn't saying to Name 2 other DEs.
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...
There isn't a Qt version of GIMP...
Linus Torvalds and I love Gnome 3.
Achille Talon
Hop!
BTW, it is not about Gnome 3 anyway, it is about the toolkit on which Gnome 3 happens to be based. You probably run some GTK+ based application, even if you use KDE, Unity, XFCE or anything else.
Achille Talon
Hop!
Sorry GTK/GNOME, but I am done. I'm fed up with trying to use your API. I'm fed up with trying to shoehorn my systems to fit your paradigms. All I want to do is make a Linux version of a tool I had on Windows, but you won't let me focus on that. Rather you want me to make some weird touch centric/single display centric application which I have no wish or desire for. I am going to move to GNUstep. Yes the API doesn't shift quickly. But I consider this a good thing. An API that for 20 years has allowed users to choose Apple menus, windows menus, or NextStep style menus. There's a lot of freedom and choice in a platform that let's the user decide the UI paradigm they want to use, and which doesn't ram their paradigm of choice down your throat. I am also moving to an api that is inherently cross-platform from day one.
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.
Because both are in use, and benefiting either is valuable.
This is true even if Qt is better than GTK in all respects.
I used to professionally develop GTK+ applications in the mid-2000s. It wasn't excellently maintained even then, but nowadays it's woeful. While it's nominally cross-platform the reality is it's always been in a state of partial brokenness on MacOS and Windows. You couldn't ever truly rely on it for cross-platform work.
I moved completely to Qt over the last couple of years. I still prefer the container model of GTK+, but the quality of the Qt toolkit is so much greater that a minor design difference is neither here nor there. If I was evaluating which toolkit to use for a new project today, Qt would be the default choice; GTK+ wouldn't even be on the shortlist. If I had to propose it for use to the rest of my team, I'd be laughed out of the room, and not unjustifiably.
Looking at the level of OpenGL support with this new work, it looks useful, but quite limited compared with what's in Qt. For example, with Qt the GL context has the ability to select which core profile you want to use and you can subclass your widgets with the GL functions you need to use, saving the need for GLEW or other GL wrappers. And it also has helper classes for wrapping shaders, accessing uniforms, and a whole bunch of other useful stuff which makes using GL vastly nicer than using the raw C API (though this is of course possible). I don't see any equivalent to these facilities in the GTK+ work.
Well, I haven't tried it in a few years, but the last time I found it intensely horrible, to the extent that it was unusable. OTOH, for most of what I do I prefer Inkscape over the GIMP.
I think we've pushed this "anyone can grow up to be president" thing too far.
Not everything. SystemD still lacks a good, stable and easy to use init system.
Why not use GTK2. That'll teach them lol. At this point it won't go away like Motif and other toolkits?
I'm curious about what would be above GTK+3 on the list. Tcl/tk, FLTK 1.3 maybe?
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
How abou Swing/Java or JavaFx?
IMHO it beats all the C/C++ stuff, is cross-platform and have a bunch of open and commercial widget libraries. And, with Eclipse or Netbeans, and maven you have much better developing tools that are free, and you don't have to compile anything.
With jogl or JMoneyEngline you can access OpenGL if you need.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
He uses C++ and Python. Why in hell would he stoop to Java? You don't meet many experienced C++ programmers who want to spend their days using Java instead, now, do you?
In terms of features Krita is great, but it's also very slow and sluggish. Just doing basic stuff like scrolling the view around makes it use 100% CPU and render at like 5FPS, even on a trivial single layer image. This sluggishness makes it not very fun to work with and it has been that way for years.
Agreed. At least pyGTK is very straight-forward to use, even for someone like me with little GUI programming experience. I can't really speak for QT tough.
Yeah. Ususally the only bad thing is some warnings in the terminal that "XX is depreciated"
GTK's answer to the Qt's 'MOC' preprocessor is Vala: a whole C#-like language, just for GObject, which compiles to C.
You don't meet many people who want to work with tools other than what they're used to, in any field.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
They completely passed my mind while writing my reply. While I do have quite a lot of exposure to Java and Swing at work, I'm afraid to say my experience is not hugely positive. For the applications I maintain, the default (metal) look and feel on Linux is awful, though some distributions do replace this. While it certainly does work on all supported platforms, I'd have to say that I do prefer Qt by far, since its native look and feel is almost perfect on all platforms in my experience, and performance also enters the equation once you start doing OpenGL stuff, if not before. Stuff like jogl also uses JNI and this also affects platform support--needing to ship the native parts compromises the portability since you restrict the platforms you can deploy on. I do think that it's less effort, more robust and gives better platform coverage to build natively. Building the JNI wrappers for every platform is doubtless possible given sufficient effort, but a pain to build, integrate and test. Last time I tried to build this from source it turned out to be impossible; I do have concerns that the mess of dependencies that maven drags down is not independently rebuildable, and that's not even getting into the security concerns.
Thanks for giving us a serious and informative answer. What OpenGL version does the driver have to support in order to get a GL accelerated canvas in Krita? I know WebGL doesn't work in Firefox on Intel GMA 3150 because its driver only supports OpenGL 1.4.
Touche. If I was a web developer working with all those nifty Java class libraries for doing webby things, I wouldn't want to use C++ either.
I have a very positive opinion of Metal L&F, I use VisualParadigm and FreeMind, both are Java applications. I don't think that the L&F matters as much as people always say. The performance of Java apps is on par with C/C++ and Maven is a huge win, because I can use just any lib that I want and the dependencies are automatically resolved. Much like the package manager on Linux. And that I don't have to compile anything is also a huge win, it's was always a pain to compile C/C++ applications.
Any OpenGL lib will be platform dependent, so I don't think your point is valid.
"I do have concerns that the mess of dependencies that maven drags down is not independently rebuildable, and that's not even getting into the security concerns."
I don't understand what your concern here is. Maven is like the package manager from Linux, and the whole point of maven is to be independently rebuildable.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Get over yourself and your One True Way, Holier Than Thou attitude
Funny, that's my boilerplate response to GNOME these days.