[GtkGLExt] GTK3: additional considerations

[Mike Paul <mike wyzardry net>]

Since this'll take some more research before significant progress can be
made, I thought I'd share a few additional porting issues I've
identified.  I'm learning about this stuff as I go along, so any
insights from people with more experience than me would be welcomed.

The first issue is colormap handling.  GdkColormap no longer exists in
GDK3, but we have gdk_gl_config_get_colormap() that returns one, and
it's used in the implementation of GtkGlWidget to install the GL
widget's colormap into the top-level window that contains it.

(Indexed color support isn't very interesting these days, especially for
OpenGL, but if it works currently, I'd prefer not to break it.)

According to the GTK3 porting guidelines:  "For drawing with cairo, it
is not necessary to allocate colors, and a GdkVisual provides enough
information for cairo to handle colors in 'native' surfaces. Therefore,
GdkColormap and related functions have been removed in GTK+ 3, and
visuals are used instead."

I'm thinking I'll remove gdk_gl_config_get_colormap() from the API and
push GtkGLWidget's colormap installation needs down into the
platform-specific backend code that can work with raw X11/Win32/etc.
colormaps.  That should work, but it may be a little klugey.  Cairo
presumably has to deal with this too, when a cairo surface is placed
into a toplevel window on an indexed-color display, so I'd like to find
out how it's implemented there; it may be informative.

The other issue relates to GTK backends.  On my Debian system, the GTK 2
library is named "libgtk-x11-2.0.so.0", and on a Windows system it's
"libgtk-win32-2.0-0.dll".  But GTK 3 is simply "libgtk-3.so.0" and
"libgtk-3-0.dll" -- the backend isn't part of the filename.  According
to [1], that's because it can be built with support for multiple
backends in the same library.

I'm wondering whether GtkGLExt ought to follow the same strategy.  If
the system's installed GTK and GDK libraries are built with both Xlib
and XCB support (for example), an application can presumably be run
using either backend, without recompiling it.  But if GtkGLExt continues
to build separate libraries for each backend (e.g.
"libgtkglext-x11-2.0.so.0" and "libgtkglext-xcb-2.0.so.0"), the
application can only link against one of them, so it'll fail if it's run
using the "wrong" kind of connection to the X server.

This isn't an immediate concern since there doesn't seem to be a
released XCB backend for GTK (though I didn't spend much time looking),
nor a widely-accepted port of the GLX API to XCB.  But if we make the
change later, it breaks ABI so existing apps have to be recompiled.
Right now, there are no existing apps linked against GtkGLExt 2, so it's
the ideal time to do it, if it's really the right thing to do.

That's all I have for now.  I think I'll focus on studying the colormap
issue, since getting it resolved will be a definite step forward and it
may turn out to be relatively simple if cairo provides a good example to
follow.

  [1]: http://developer.gnome.org/gtk3/stable/ch25s02.html#id1400118
-- 
Mike Paul <mike wyzardry net>