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

[Mukund Sivaraman <muks banu com>]

On Mon, Jan 11, 2010 at 01:36:47AM -0500, Arc Riley wrote:
> There is no license issue.  GLEW is under the BSD, at worse you include the
> BSD boilerplate in the header and copy/modify their headers.  It's fully
> compatible with both v2 and v3 of the LGPL.

We cannot combine code that has a similar license to the BSD license
(non-copyleft), with LGPL licensed (copyleft) code.

You can link in between these, such as a program linking to a library,
but not form a single binary object from it, such as a .so containing
both LGPL and BSD licensed code.

I'm not a lawyer. This is our interpretation of these licenses, and
what we'll stick with.

> More importantly, GLEW and gtkglext overlap in more ways than glext.h.
> There's enough dependency bloat in the Gnome community, not to mention
> redundant functionality taking up valuable memory and causing cache misses
> that hurt performance.  GLEW is barely enough to constitute a full library
> in any event.  That's one less dependency to worry about.

gtkglext is a simple way to get an OpenGL context for a GTK+ widget. It
is not an OpenGL convenience library.  It is not intended to:

 o Provide a scenegraph
 o Do input handling, window management, etc.
 o Draw geometric shapes
 o Provide convenience wrappers for GL/GLX/etc.

After you get an OpenGL context, you simply use GL or any other
convenience libraries afterwards.  This similar to how Cairo is used in
GTK+ for example.

You can still query extensions with gtkglext. We intend to keep this
functionality available.  The library uses it internally too.

> A third and trivial issue is that GLEW is an immature library on GNU/Linux,
> a really basic build system (static makefiles that break if the GL headers
> are not where they're expected) and no pkg-config file.  GLee even moreso,
> it's not even packaged in most distros.  It's a headache for upstream
> packages to configure and build with them and really unnecessary given
> gtkglext already providing much of the platform agnosticism GLEW is commonly
> used for.
> 
> I'm volunteering to expand gtkglext to fully replace GLEW.  It'd be less
> work for me than continuing to use GLEW in our engine.

This would be a waste of time. We don't intend to reinvent the wheel,
especially when such wrappers would look exactly like GLEW/GLee. This
was discussed a few weeks ago among the maintainers.

If you have a problem with GLEW, your time is best spent fixing it, and
pushing patches to its maintainers, so that GLEW gets a pkg-config
file, a configure script and other goodies that end-users wish upon.

This would take up far less time, than re-implementing GLEW inside
gtkglext, where it does not belong.

If you don't like GLEW's quality, then there may be other such
libraries to choose from.  But it has nothing to do with gtkglext.

		Mukund