[ruby-talk:7602] Re: A Java Developer's Wish List for Ruby

   > And I think that's an important point. We're not deciding here which
   > library developers must use. We're simply debating the pros and cons
   > of individual libraries. Eventually, the conclusions we reach may
   > affect which libraries get included in various distributions, but
   > we're not doing anything that prevents a team from using any GUI
   > library they want.

Yes, I agree that there's always the next library out there that will look
better, and so forth. I don't know if this approach would make it, you have
a set of graphics primitives defined and then anyone who wants to hook in
the right system would just write code against the primitives. Actually I
don't like this myself, as it will just confuse everyone. So maybe best to
have specific bindings for each toolkit and let people choose, i.e. Fox
bindings for the Fox kit.

Now, if you want to go with a Java-Swing implementation, where most of the
graphics in Swing is Java code, and some parts are optimized, that's another
story.  Then you need to write Ruby code, and have selected bottlenecks for
the actual drawing. This is how for example the original Macintosh drawing
system operated, it had selected bottlenecks for optimization and such. We
used Newton for a lot of drawing with the exception of the low level
bottlenecks (used a portable QuickDraw kit), so an interpreted language
works quite well with drawing purposes.

It's fun to speculate, but if you do this (native Ruby drawing environment),
do it better than the rest, include animation and vector graphics support
from day one (style Flash of SVG). That way you have a good reason for using
the graphics system. If I would make a new drawing kit from scratch I would
really go with a vector graphics format and animation, gives you enough
flexibility for a long time. --Kent