RE: GtkGLExt (was Re: Gtk 3.0)




I've sort of followed this chain.... sorry if I am rehashing something that has already been covered.
IMHO I agree that GtkGLExt should be directly integrated into GTK. Most modern user interfaces (IE OS X 
(NextStep)) are integrating 3D directly into the windowing system. If I am not mistaken the panel is pure 
Open GL in OS X, and for sure the iChat multi session video window is pure OGL with reflection maps (they 
love to tout that). Their development toolset is chalked full of OpenGL examples, and composer... well I 
won't even go there. GTKGLext does NOT currently work well on OS X interface (even though there is a patch 
for it, which still needs to be changed to use the NSOpenGLView instead of the NSView but that is whole other 
story).
Open GL is not only the standard scientific toolset, it is the de facto hardware acceleration tool set. I 
don't know of ANY video card vendor that DOES NOT have OpenGL support. In fact I can not think of any other 
hardware accelerated tool sets (OGL has been it since the early 90's) it WILL be the interface choice of the 
future. 2D desktops will quickly give way to 3D widgetry, as hardware acceleration improves even further. 
Just look at compiz!
I've already got users asking me to make the app look more 3D, and it would be great to have the toolset to 
do so. Even though all were doing is simple EPR stuff. IE If I could create a 3D warehouse map that was 
navigable by the user to see where they have room to store a product, or look at a product space for a visual 
cue to order more. This is an old concept Motorola developed about its factories and training workers 
virtually. 
Of course, this is all a wish list, I can't demand of the community to do the work I my self have no time 
for, but it would be really really really supercalifragilisticexpialidocious-ly great to have a fully working 
OpenGL implementation in GTK for OS X, and if it is dropped for GTK 3.0, I'm afraid it will not serve the 
community well. 

I did not quite catch why it was not a good idea. Saying that is like saying it is not a good idea to have 
the printing subsystem, or input subsystem be exposed in GTK. GTK in essence is an abstraction layer, to hide 
the differences in interface functionality, giving the user (programer) a singe interface to write agains. 
Why should we not have the same thing for OpenGL, which is a component of the user interface?
Again this is all MHO, and I certainly have not invested a dime in it, so wether it happens or not I will 
work around it, but it would be nice, very, very nice, to have an GTKOGLWindow in GTK's base library, or at 
least something like pango/cairo, as a compiler option module.

 EMAILING FOR THE GREATER GOOD
Join me

Date: Fri, 4 Dec 2009 22:26:05 +0100
From: yeti physics muni cz
To: ebassi gmail com; jose carlos pereira ist utl pt
Subject: Re: GtkGLExt (was Re: Gtk 3.0)
CC: gtk-app-devel-list gnome org

On Fri, Dec 04, 2009 at 08:51:54PM +0000, Carlos Pereira wrote:
I'm really not working on it - mainly for three reasons: 1) if you want to
use GL, GtkGlExt is "good enough" and integrating it into gtk+ it's not a
good idea;

2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt.

4) Scientific/engineering applications often use OpenGL,

Exactly.  I've been using GtkGLExt in a scientific app for years and I'm
quite happy with it.  Cutter does not cut it if you need to visualize
scientific data in 3D.

Unfortunately, scientific/engineering apps seems to *be* niche use.  Look
at how hard SourceForge tries to hide this software category even though
it contains 50× more projects than VoIP which is promimently displayed...

So I hope something like GtkGLExt will continue to be available, whether
it's called GtkGLExt or not and is integrated into Gtk+ or not.

Yeti

_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
                                          


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]