[ruby-opengl-devel] Project status
jan.dvorak at kraxnet.cz
Tue Feb 20 23:17:45 EST 2007
On Tuesday 20 February 2007 04:55, Al Hoang wrote:
> Interesting. This is something I didn't consider at all but something
> definitely that makes sense. Well putting in this support now is good
> although at the current moment, ruby-opengl doesn't do much to build
> anything on win32 at the moment. I'd really like to have this fixed but
> mkrf itself doesn't seem to support building on win32 except perhaps
> via cygwin so most likely changes to mkrf will have to be made to support
I don't think that is that much of an issue. The code itself compiles on win32
cleanly. Now, i'm newcomer to ruby, but i have some idea about the
distribution system, as well about the problems with compiling extensions on
windows. I've seen that most ruby extensions on win simply distribute
binaries (either as .exe installer or as binary .gem). We don't use any
external libraries (apart from glu/glut) or API, so i guess we can simply
have one-size-fits-all binary and distribute it as gem, and also (when it's
complete and tested) ask the ruby-lang guys to include it into the windows
one-click installer (which happens to currently include the original Yoshi
> This sounds perfectly fine. In fact it's probably already in the svn
> trunk since I committed your patch a couple of hours ago.
I didn't include it in the patch just to be on the safe side. Also i have to
yet test it on MacOSX (currently trying to install it into emulator :) ).
There's also the issue that MacOSX 10.3+ uses different dynamic loading
functionality (POSIX-like dlopen) then older versions - how much are versions
<10.3 prevalent on the market ? I ask for whether we should support both
interfaces, or just stick with the modern one for this. Of course even in
that case, users of older MacOSX version will still be able to use 1.0/1.1
functionality (which is the whole functionality of the bindings as of
now :) ).
> This sounds fine. I actually think what would be handy is to have
> a small thumbnail picture that should resemble or be a smaller rendition
> of what the user should expect to see. If the files aren't that large
> we can stuff them in the test directory under the same name as the test
> itself for easier identification.
Thats good idea.
> This might not be a bad idea at all or perhaps we can try to take
> advantage of Ruby's DL library to bind to the GLU library dynamically.
Also good idea, i wasn't aware of this.
> Perhaps, GLUT could just stay the way it is in ruby-opengl as I'd
> imagine people would move onto some other windowing toolkit if they wanted
> more features than what the current basic GLUT interface can provide.
I'd say you're right, although there aren't exactly that many windowing
toolkits available to ruby capable of creating GL context for now. Anyway, i
know that there are one or two functions missing from Glut core functionality
(like leaving fullscreen mode), but i haven't yet time to really look at what
other stuff is missing.
More information about the ruby-opengl-devel