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.

Re:

[NotInHere]

Its good to have choice. If there is none, things like heartbleed or winshock can happen.

Re:

[weilawei]

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.

Re:

[sunderland56]

Some of us prefer GTK over Qt.

So then *you* help them out.

I'm a OpenGL/Linux/kernel/lib developer, and there is no way on God's green earth that I will contribute anything to Gnome.

Re:

[geminidomino]

Get over yourself and your One True Way, Holier Than Thou attitude

Funny, that's my boilerplate response to GNOME these days.

Re:

[Iconoclasism]

There isn't a Qt version of GIMP...

Bring out the Krita

[tepples]

What's wrong with Krita [wikipedia.org]?

Re:

[HiThere]

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.

Re:

[tepples]

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.

Re:

[Ingo Ruhnke]

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.

Re:

[Wootery]

Because both are in use, and benefiting either is valuable.

This is true even if Qt is better than GTK in all respects.

Re:

[kyrsjo]

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.

Re:

[Wootery]

GTK's answer to the Qt's 'MOC' preprocessor is Vala: a whole C#-like language, just for GObject [gnome.org], which compiles to C.

Re:

[weilawei]

How about 23 [wikipedia.org]? Look at the gallery for just a sampling.

Re:

[Desler]

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.

Re:

[AchilleTalon]

Linus Torvalds and I love Gnome 3.

Re:

[AchilleTalon]

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.

Re:help them

[xiando]

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.

Re:help them

[L-One-L-One]

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...

Re:

[kthreadd]

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.

Re:

[kyrsjo]

Yeah. Ususally the only bad thing is some warnings in the terminal that "XX is depreciated"

Re:

[Blaskowicz]

Why not use GTK2. That'll teach them lol. At this point it won't go away like Motif and other toolkits?

Re:

[rl117]

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

Re:

[Blaskowicz]

I'm curious about what would be above GTK+3 on the list. Tcl/tk, FLTK 1.3 maybe?

Re:

[rl117]

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 possibil

Re:

[devent]

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.

Re:

[Gibgezr]

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?

Re:

[ultranova]

You don't meet many experienced C++ programmers who want to spend their days using Java instead, now, do you?

You don't meet many people who want to work with tools other than what they're used to, in any field.

Re:

[Gibgezr]

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.

Re:

[rl117]

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 a

Re:

[devent]

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 OpenG

Ob

[Hognoxious]

Would love to, but I'm busy writing a combined init system, web server & tic-tac-toe engine.

Re:

[wonkey_monkey]

The only winning move is not to boot.

Re:

[fibonacci8]

Emacs users never fail to surprise me.

Just use SystemD

[Billly Gates]

It does everything

Re:

[Anonymous Coward]

Not everything. SystemD still lacks a good, stable and easy to use init system.

Re:

[BitZtream]

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

Re:

[Desler]

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.

GNOME toolki? nope GIMP Toolkit

[xiando]

GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. http://www.gtk.org/ [gtk.org]

Re:

[kthreadd]

Well, except that in this case the entire story is that they want help making it work great on non-Gnome platforms.

Re:

[Anonymous Coward]

gtk2 did... then gnome devs went on a remove fucking everything spree and now noone except the gnome folk wants to use it.
gtk should rename itself to gnome tk and die with gnome.

Re:

[Anonymous Coward]

is a multi-platform toolkit

Meaning it once supported GNOME 2 and now supports GNOME 3. There was a nice presentation on one of Linus open source projects migrating to Qt since nobody in the Gtk community gave a shit about support in general and Windows support in specific. They put a C++ UI library on top of a pure C code base because Gtk is just that bad an alternative.

Re:

[kthreadd]

According to the story you just commented on they apparently care quite a lot about cross-platform support since they want people to help them with it.

Re:GNOME toolki? nope GIMP Toolkit

[MrEricSir]

Actually, GIMP still uses GTK+2.

Patch in progress for Quartz/Mac OS X

[brion]

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... [gnome.org]

thanks. I can only test

[raymorris]

Thanks for your work on that. I'm npt familiar with graphics programming at all since my work always uses either a cli or browser-based GUI, but I do have some Macs around for testing and such.

Help Redhat's hostile takeover of Linux?

[walterbyrd]

No thanks.

These days: Redhat == Microsoft.

I am surprised that more people don't see that.

Qt...

[Tough Love]

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.

Re:Qt...

[sfcat]

Couldn't agree more. I spent 3 years writing an OpenGL app using GTK+. I just spent the last 6 months porting it to QT. And even with having to using C++ in places in the code (I wanted it to be pure C) I couldn't be happier with QT. And I probably couldn't be less happy with GTK+. When I finally got the GTK+ version working on windows, it had terrible performance. GTK+ is a total mess developed by people with no desire for you to use their code. For years the GTK+ devs actively questioned the usefulness of supporting OpenGL and refused to even answer questions about the OpenGL support. The devs are openly hostile to things like OpenGL and they break compatibility on a regular basis. The QT version of my app's code has probably 30000 fewer lines due to far more sane APIs and much more useful widget APIs. Why anyone in this day would use GTK+ for anything unless they were required to use only pure C in their app is beyond me.

Re:

[luminousone11]

Does QT use xlib or xcb under the hood on X11 based systems. I ask because I would like to thread applications without worrying about the finicky nature of xlib when threading is involved.

Re:

[sfcat]

Does QT use xlib or xcb under the hood on X11 based systems. I ask because I would like to thread applications without worrying about the finicky nature of xlib when threading is involved.

I'm not 100% sure but I think xlib. xcb is mostly dead these days, or so I get that impression. I really wish xcb had more traction but only a few apps need this type of multi-threaded GUI functionality (my app being one of those few) so it seems to get left behind.

Re:

[Anonymous Coward]

Qt5 uses xcb. The platform plugin for X11 is even called... drumroll... qxcb.

Qt4 uses Xlib.

Re:

[strikethree]

I like your .sig

"Those that start by burning books, will end by burning men."

Where is it from?

Sorry GTK

[DMJC]

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

Re:

[HiThere]

GNUStep is very interesting, but every time I've tackled it, I've bounced. Sometimes I literally couldn't figure out how to do things, other times it's just that it was too difficult to bother.

They *REALLY* need better documentation. Probably the toolkit is fine. Every time I worked at it long enough I was able to make it do what I wanted, but the documentation is truely terrible. And it needs to be written by someone who already understands the system.

If the GNUStep documentation had been better, I'd p