I haven't yet paid much attention to some of the more esoteric issues such as multithreaded applications, or interactions with other popular Ruby extensions. FXRuby seems to cooperate well with Ruby's thread scheduler on all platforms, although threading support for the mswin32 build of Ruby was broken for Ruby versions 1.6.7 and earlier. For best results, use Ruby versions 1.6.8 or later.

More examples are always good. Instead of (or in addition to) merely cloning the C++ examples from the standard FOX distribution, it would be nice to have original example programs that demonstrate Ruby's special strengths.

Documentation is of course a big weakness at this point. I am slowly building up a set of "pseudo-sources" with RDoc-style comments that can be used to generate API documentation but this is far from complete (see the rdoc-sources directory in the standard source distribution).

Many people have expressed interest in a framework similar to Tk's Canvas widget that allows you to draw and drag 2-D shapes around, etc. Should be able to implement this kind of thing directly in Ruby code (i.e. no need to write it in C++ first and then "wrap" it).

There is no native Mac OS X port of FOX, but many people are successfully building and running FOX and FXRuby applications on Mac OS X using Apple's X11 server implementation. For more information, please see the Mac OS X page at the FOX Community Wiki site.

Need to investigate how well FXRuby-based applications work with exerb, and perhaps add a section to the documentation about how to do this.

As of this writing, FOX doesn't provide any support for internationalization (I18N) or Unicode text and so FXRuby doesn't either. It is possible that FOX 1.2 will include some I18N support (see the FAQ at the FOX Community Wiki site), and if so, appropriate changes will be made to FXRuby at that time.

FOX's list-like widgets (such as FXList) behave differently from Ruby container objects (such as Array) in the sense that when a list widget is destroyed, it typically destroys all of its contained items at the same time. One consequence of this behavior is that you can end up with Ruby objects that refer to dead C++ objects (a variation of the dangling pointer problem familiar to C/C++ programmers). I would like to see if this behavior can be modified for FXRuby so that it's impossible to end up with these "dangling references".