Re: [GtkGLExt] API changes for the next major gtkglext release (glext)
- From: Arc Riley <ArcRiley pysoy org>
- To: Braden McDaniel <braden endoframe com>
- Cc: gtkglext-list gnome org
- Subject: Re: [GtkGLExt] API changes for the next major gtkglext release (glext)
- Date: Mon, 11 Jan 2010 17:50:34 -0500
On Mon, Jan 11, 2010 at 4:30 PM, Braden McDaniel <braden endoframe com>
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.
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.
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.
] [Thread Prev