On Mon, 04 Aug 2003 10:53:24 +0900, Richard Kilmer wrote:

> WxRuby is close to an initial (very early) Alpha release.  It will be 
> released in that (early) stage within the next few weeks.  The author, 
> Kevin Smith, is actually using it to construct an email application for 
> himself as both a learning exercise, and to demonstrate/document the 
> WxRuby API.  Several folks across various platforms are working on 
> testing the early release on win32, mingw, os x and Linux (which Kevin 
> runs).  I must say that Kevin is making great progress.
> 
> The project is currently on Savannah, but is moving to RubyForge (over 
> the next few days) here:
> 
> http://rubyforge.org/projects/wxruby/

This probably isn't the right place to ask, but I've a quick question.  I
just grabbed a CVS version, and compiled it with no difficulties.  But
what strikes me about the samples is that they seem slow.

Basically, everything lags a little bit.  Redraws can be easily seen.  If
you open a big menu and move the mouse over it, the selected item lags
behind the mouse.  wxWindows doesn't do this, and RubyGnome2 doesn't do
this.

I think it might be a problem with how the message loop interacts with
Ruby's threads.  RubyGnome2 uses g_main_set_poll_func(), which sets a
poll function to be used in glib's message loop.  rbgtk's poll_func,
rbgtk_poll(), translates it's arguments to the right format, then calls
rb_thread_select().

A quick grep of wxRuby source shows this isn't used.  I'm not a wxWindows
hacker, but there may be a similar way to replace the poll() at the heart
of wxWindows, so it too would play nice with Ruby's threads.

<http://developer.gnome.org/doc/API/glib/glib-the-main-event-loop.html#G-MAIN-SET-POLL-FUNC>

-- 
Tom Felker

If a vendor refuses to submit specs, they're obviously trying a cheesy lock-in 
scam and shouldn't be considered anyway.