[fxruby-users] FLTK2

gga ggarra at advancedsl.com.ar
Fri Jan 19 23:43:15 EST 2007

Lyle Johnson wrote:
> Since I haven't seen the source code for your FLTK2 bindings, I can't  
> say for sure why there would be such a significant size difference  
> between it and FXRuby. I am a little curious about how you're  
> handling things like overriding virtual function calls in Ruby, as  
> well as garbage collection related issues. I know that the code  
> required to support those things takes up a significant part of the  
> FXRuby code base.
While it is not likely I'll make an announcement until I have fluid
fully written in ruby, you can already take a look at the source with:

svn checkout svn://rubyforge.org/var/svn/fltk

Things different from FXRuby:
- inheritance and virtuals are handled by SWIG, using directors and
This change reduces the code to maintain in the binding to about 1/2 of
what FXRuby is currently using, as there's no need for Rb* classes as in
Well, technically, SWIG DOES create something equivalent to Rb* classes
itself and I had the SWIG team more or less rewrite their SWIG director
code for 1.3.29 onwards to handle this better.  Have not delved deeply
into the FXRuby source to see if the Rb* classes have any merit over the
SWIG ones.  Mind you, directors for ruby in swig were pretty much broken
until I got to debug them over swig 1.3.28, so you do need some recent
swig version.
To do a mapping between C/Ruby classes at any point, SWIG's tracking
uses a hash mapping.  Personally, I think SWIG's code could still be
improved here, by using a faster hash, like google's densehashmap.
- Callbacks are also handled in C, unlike FXRuby's overriding of
method() in ruby.  I use duck typing within the C code.  Mainly also
because Matz has forgotten to expose rb_cMethod in the 1.8 branch.
- Exceptions are also handled by SWIG itself.
- Drawing functions are exposed also directly, sans going thru ruby.
- FLTK2.0's binding takes advantage of mapping :symbols to method
callbacks within C directly.  This is still not as generic as I would
like, due to Ruby's limitations internally, but the idea is to allow both:

      w.callback( method(:myfunction_cb) )
      w.callback( :myfunction_cb )   # treat :symbol as a method in the
running scope, automatically
                                                        # binding to the
                                                        # (currently
this works for global methods in Object only, sadly)

- FLTK2.0's binding takes advantage of Ruby's DSL features, by using
instance_eval within blocks instead of yields on its constructor.  This

  window = Window.new( 300, 180 ) {
    callback :window_callback

instead of a more convoluted:

  window = Window.new( 300, 180 ) { |w|
    w.callback :window_callback

  w = Window.new( 300, 180 )
  w.callback :window_callback

However, the other syntaxes are also efficiently supported.

SWIG/FLTK still pending issues:

- Currently, there are still I think some issues using SWIG classes
across multiple DSOs, but for something simpler like FLTK which is just
1 dso, it is no issue.
- There's still some segfault issues, albeit these seem more FLTK2
issues, than binding issues.  Currently, the fonts listing api will
often segfault on my machine.  This happens to me also with FLTK in C++,
thou, but I cannot get the FLTK developers to reproduce it on their
environment. It seems something funky is going on in FLTK's X11 code for it.
- Sometimes if ruby rises a syntax error, upon quitting SWIG does seem
not to handle its unloading properly and sometimes it will also raise a
segfault.  I still need to delve into this one also more fully, but it
is not 100% critical.  It might be unavoidable, due to use Ruby's
internal use of longjmp?

Off the list, I was also talking to Jeroen about FXRuby's size.  He did
seem to have found a bug in the Makefile and a way to reduce Fox symbols
size a little bit more.
He also made me realize that for FXRuby and my own FLTK's bindings, it
could be interesting to compile the actual FOX/Fltk library as a static
library within the ruby dso, as that would remove all symbols from it,
which would bring the FXRuby lib to 4mb and the FLTK lib to about 400Kb
from their 12Mb and 4Mb size.   The only disadvantage of doing so would
be that Ruby users would need to recompile the extension every time they
upgrade the underlying toolkit library.

Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
Kubuntu Edgy

More information about the fxruby-users mailing list