GTK+ Gains Native Support For OpenGL

[phoronix]

Phoronix: GTK+ Gains Native Support For OpenGL

For GTK+ 3.16 there is now native support for OpenGL along with a new widget type. The GTK+ OpenGL support works on both X11 with GLX and under Wayland with EGL...

http://www.phoronix.com/vr.php?view=MTgxMjg

[gufide]

well, that's Qt

[oleid]

well, that's Qt

That does mean exactly what?

By the way, you can use OpenGL within GTK+ for ages using an external widget.

This new integration, however, is really cool! You can now draw directly to cairo. Thus, it's now possible to e.g. draw rasterized 3D graphics to e.g. PDF files. This is nice for sure!

[darkcoder]

Good to GTK+ community, but...

It's good news to the GTK+ devs, because is not the same an optional widget than support straight in the code base. But...
the problem is in the same news topic. Again like some months ago it was brought to the attention that only Linux was giving the full development attention, and other platforms like Windows and Mac were treated as second citizens, there is no mention of support for OpenGL content neither in Mac OS nor Windows codebase (ports make more sense).

That's the difference with Qt. It gives more importance to the as they said "Deploy Anywhere"

And that's why many projects each day move from GTK+ or custom (Win/Net) projects to Qt. Even the new Blizzard laucher is now made with Qt.

[carewolf]

That does mean exactly what?

By the way, you can use OpenGL within GTK+ for ages using an external widget.

This new integration, however, is really cool! You can now draw directly to cairo. Thus, it's now possible to e.g. draw rasterized 3D graphics to e.g. PDF files. This is nice for sure!

It would be even better if they didn't rasterize it, since PDF is also a vector format.

The Qt comment is probably due to Qt supporting OpenGL (and even native PDF) versions of QPainter for at least half a decade. It is pretty neat, but not the end all. Especially since developers tend to use a traditional widget painter in ways that are inefficient on OpenGL.

[oleid]

It would be even better if they didn't rasterize it, since PDF is also a vector format..

AFAIR there is a library which supports GL vectorization, however I forgot the name :/ glps or similar...

Edith:
Here it is :
http://www.geuz.org/gl2ps/

[liam]

It's good news to the GTK+ devs, because is not the same an optional widget than support straight in the code base. But...
the problem is in the same news topic. Again like some months ago it was brought to the attention that only Linux was giving the full development attention, and other platforms like Windows and Mac were treated as second citizens, there is no mention of support for OpenGL content neither in Mac OS nor Windows codebase (ports make more sense).

That's the difference with Qt. It gives more importance to the as they said "Deploy Anywhere"

And that's why many projects each day move from GTK+ or custom (Win/Net) projects to Qt. Even the new Blizzard laucher is now made with Qt.

The advantage for targeting linux especially is a simplified, and potentially more performant, codebase. I'm not saying gtk is such a codebase, but there is an advantage to going full native like cocoa or wpf. Additionally, the exposed api could be a great deal simpler for developers, and make it harder to do the "wrong thing".
Is there an updated list that shows how projects are being move "each day" away from native toolkits?

[gufide]

That does mean exactly what?

By the way, you can use OpenGL within GTK+ for ages using an external widget.

This new integration, however, is really cool! You can now draw directly to cairo. Thus, it's now possible to e.g. draw rasterized 3D graphics to e.g. PDF files. This is nice for sure!

It's a reference to Qt's QML which uses OpenGL and OpenGL ES to display widget and animation. Qt is commonly pronounced "cute" so it's a pun that makes a reference to a Qt feature that they got for a long time in the sentence "that's cute".

I'm quite happy that GTK support this! That would certainly make the toolkit better. If they work more on that, we could even embed GTK widget in a existing context, like a game engine and so on.

[mark45]

By the way, you can use OpenGL within GTK+ for ages using an external widget.

That stinky external widget was never updated to work with gtk3, at least last time I checked a few years after gtk3 was released.

Not to mention that gtk sucks because it's written in C, because of that it sucks as a C++ solution, and because C sucks for GUI development gtk has become a gimmick for python aficionados. That's why I moved to Qt, there was GL support with Qt5 from the start, and later GL was integrated into the Qt5 gui subsystem. Qt 5.4 will improve the support even further. That's quality baby. And I don't have to deal with the shitty Gtk design and C programmer mindset.

[oleid]

That stinky external widget was never updated to work with gtk3, at least last time I checked a few years after gtk3 was released.

Not to mention that gtk sucks because it's written in C, because of that it sucks as a C++ solution, and because C sucks for GUI development gtk has become a gimmick for python aficionados.

If you don't like C, why don't you use GTK--, the official C++ wrapper for GTK? I think it's a bit nicer than Qt from API point of view.

You can also use the C++ version of GTKGLExt, which you find on it's homepage.
https://projects.gnome.org/gtkglext/index.html

If you'd complained about the bad cross platform support of GTK, then I'd totally agree. But complaining that the library is written in C is plain nonsense, considering there is a really nice C++ version -- which even doesn't need something like MOC -- and considering that not every language on the planet has C++ binding support.