> Wayne Vucenic wrote:
> >
> > This is exactly what wxWindows provides.  I used wxWindows a bit about
> > a year ago.  I was only programming on Windows, but my understanding
> > is that I could have taken my code and recompiled it on Linux or one
> > of the other supported platforms, and it would have run there with
> > (essentially) no changes.
>
> Yes, this is true.
>
> > I think wxWindows deserves a closer look.  It seems mature and stable,
> > has a fairly large and energetic group of people enhancing it, and
> > many programmer-years of effort have been expended on it.  I
> > especially like that it has been around about 10 years, and has wide
> > support, so it's unlikely to go away anytime soon.
>
> Tom, I agree with Wayne here -- I would encourage you to take another look
> at wxWindows. When the FreeRIDE project did its GUI search, wxWindows may
> very well have been our GUI toolkit of choice (it met all of our feature
> requirements), if only it had Ruby bindings.

i give my vote for wxWindows, according to my experience with wxPython. it
is the richness of the samples that really convinced me, and i invite
everybody interested to take a look

if you are willing to go through with the python installation:
http://www.wxpython.org/download.php
and some screenshots: http://www.wxpython.org/wxpshots.php


as i recall, there is currently a project to wrap wxwindows for ruby called
wxruby, but i haven't seen much activity.
(http://sourceforge.net/projects/wxruby/)


now if i may give my assessment of this situation:
--------------------------------------------------
1)	a good gui system, although not essential to some, is ESSENTIAL to the
widespread acceptance of a language. the best ruby has to offer currently is
fxruby (and it is good), but i've noticed that native look and feel is an
important desire. especially if ruby wants to gain greater popularity under
the windows market. it should offer native look and feel (and behaviour),
but of course also function on other operating systems, hence the reason why
wxwindows is a very good option.

2)	gui systems are usually MASSIVE. any attempt to create bindings, or
writing them from scratch is a massive effort. and then we haven't even gone
into keeping the system up to date, bug fixes etc.

**i would like to emphasize that one must have an idea of the immensity of
the situation.**

the impression that i get with gui projects is that they are very likely to
fail, unfortunately. even a system that makes the first step by offering
primitive support, can easily fade into the darkness. (another point in
favour of wxwindows btw: they've taken care of the entire cross OS gui
system. a thing less we have to worry about. as somebody said, doing that
from scratch is a life's work)

this is why i think that we should definitely focus on the path of least
resistance here, because if our goal is to create a new widely accepted
library, it is a rather difficult path.

3) suggested development path:
first we find a very enthusiastic leader, and a good bunch of volunteers
(i'd consider being a volunteer)

then we take the wxpython source, create scripts to translate the python
roughly into ruby (the languages reasonably similar), just to get the
skeleton of the system into realisation. very lazy, very efficient, why
would we do what others have already done ?

now follows the considerable difficult task of getting the system up and
running, and discovering the nature of our new code and its interaction with
the wxWindows system. of equal importance is to throw sufficient and
beautiful ruby idioms into the structure of the language.

well, just my two cents describing a vision how i would see things happen

regards
repeater