Re: OpenGL option for GTK+ (bug #119189)

[Tristan Van Berkom <vantr touchtunes com>]

Naofumi Yasufuku wrote:
> So please help me to realize the purpose of providing well-defined,
> flexible, multi-platform OpenGL support API for GTK+.

Hi all,
    I've went back in time and re-read our entire thread back in september
(OpenGL support in GTK+) and reviewed the RFC provided by the GtkGLExt team.

The thread in its entirety:
http://mail.gnome.org/archives/gtk-devel-list/2003-September/thread.html

The RFC:
http://bugzilla.gnome.org/showattachment.cgi?attach_id=22045


The way I'm seeing it; this is the big picture:
   - GtkGLExt is the leading strain of OpenGL for Gtk+.
   - Most seem to agree that we want an OpenGL API available through
     the GTK+ family of libraries.
   - Not /much/ work if any needs to be done for GtkGLExt to fit
     into the GTK+ family of libraries.

    The next thing that needs to be addressed is how GTK+ will be built,
installed and linked against (I dont see much sence in fantasizing about
APIs at this point except to explore the different advantages offered by
the various different approaches already suggested).


    Point 3.1 in the RFC above basicly rephrases the options suggested for
review by Owen here:
http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00254.html

I tend to agree with Sven in his reply here:
http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00241.html

Sven > IMHO, libraries improve by modularizing them. GTK+ has already grown
Sven > too large and I would welcome if it would be split into smaller pieces
Sven > instead of more stuff being added. Other people have expressed similar
Sven > opinions.

and would opt for solution 3 (of point 3.1 in the afore mentioned RFC):
     "add this support into a separate library shipped with gdk/gtk."

an OpenGL API is significantly big enough IMO to merit its own library,
furthermore; it's obvious to the developer whether they should link against
an OpenGL API or not (IMO, splitting gobject from gtk was a good move,
GTK+ should be reasonably lightweight depending on what you want
to do with it, no ?).


The problem we encounter here though is the following:

The GdkGL stuff makes sence by itself (an OpenGL drawing kit for gtk
with dependancies on the native gtk "drawing kit") and it just doesn't
make sence to me to add the "gtk_widget_set_gl_capability()" APIs into the
same library (same would apply to a GtkGLDrawingArea).

While adding theese functions to the actual GtkWidget api
    i.e. GTK_WIDGET_GET_CLASS(widget)->set_gl_capability()
makes sence semanticly; it is a nightmare in terms of dependancies
(build or otherwise).

This would leave us with a bag of orphaned initialization stubs, hmmm

    A.) Would it be acceptable to put theese functions (or this widget)
        in the GdkGL library as an exception (OTOH, is there an advantage
        to having a smaller list of distributed packages) ?

    B.) Would a seemless implementation of theese functions at the
        GtkWidget level be possible (without dependancy issues) ?
        <idea>
               gtk_opengl_init() would effectively check for the
        presence of the GdkGL library and possibly load it as a module.
        Calls to: GTK_WIDGET_GET_CLASS(widget)->set_gl_capability()
        and friends could kindly return errors when the GdkGL library
        is not present or not loaded.
        </idea>

    C.) What about "GtkGL" ? it would contain the
        "gtk_widget_set_gl_capability" api's or a toplevel
        `g_object_new(GTK_TYPE_GL_DRAWING_AREA, NULL);' implementation
        along with some cool derived widgets like GtkGLLabel with antialiasing
        and rotations and whatnot or a "LightWave 3D object viewer"
        widget like the demo that currently comes with the GtkGLExt package
        (and I guess a wealth of funky 3D stuff that would evolve with a
        GtkGL package).


This is my 2 sence,
                            -Tristan

/me humbly gets ready to get my hands dirty if possible...