Re: [GtkGLExt] API changes for the next major gtkglext release (glext)

[Braden McDaniel <braden endoframe com>]

On Mon, 2010-01-11 at 17:50 -0500, Arc Riley wrote: 
> On Mon, Jan 11, 2010 at 4:30 PM, Braden McDaniel
> <braden endoframe com> wrote:
>         The glext stuff is getting the axe because GTK+ applications
>         don't have any special needs in this department (i.e., ones
>         that aren't shared by non-GTK+ cross-platform apps).  IMO, if
>         there is a convincing argument to be made here, it's one that
>         refutes that claim.
> 
> Then why not remove context support?  GLEW provides glewContextInit
> and related functionality.  There's nothing GTK+ specific about a GL
> context.

You might not want to give us ideas. ;-)

As it stands, the GdkGLContext notion is coupled pretty strongly to that
of the GdkGLDrawable.  It is conceivable (to me, at least) that some
future alternative approach to all this might bury the context from
direct view.  But I don't anticipate anything like this happening in the
2.0 timeframe; and any such change would almost certainly be accompanied
by a deprecation period for the old API.

> GLEW also provides extension testing, so there's no need to implement
> gdk_gl_query_gl_extension beyond mapping it in the header as an alias
> to glewIsSupported.  Since any app using gtkglext 2.0 would need to
> use GLEW, why not make GLEW a dependency of gtkglext and trim the API
> down to *only* the explicit functions needed to use GL inside GDK/GTK.

I'm pretty sure this function is on our chopping block, too.

> Then you could provide gdkglglext.h backward compatibility just
> linking gdk_gl_* to the GLEW equiv and list these in the docs as
> depreciated, included only to support gtkglext 1.0 apps and recommend
> using GLEW directly instead.

We're not interested in having GtkGLExt depend on GLEW--especially not
just to provide legacy functionality.  Users who need what GLEW provides
can go directly to GLEW (or GLee, etc.). 
The next GtkGLExt release is going to require a very recent GTK+, too.
It's not going to be a drop-in replacement for GtkGLExt 1.x.  It is
targeted at new apps and those that are being upgraded to use modern
APIs.  For better or for worse, we're not really able to avoid breaking
API compatibility with the next release (bug 604333).  We're taking this
opportunity to do some additional culling of bits that represent
functionality outside the core role we see GtkGLExt taking.

-- 
Braden McDaniel <braden endoframe com>