I feel I must ask this, although it may be daft:

We seem to be discussing which GUI to tie ruby into, to ensure
the widest support.  But we don't know how things are going to 
change in the future, and such change may not be far away, in 
this field.  Should we not be providing an abstraction to which
any GUI can be attached?  I see such an abstraction as a superset
of facilities, in which some facilities for the less capable GUIs
will be emulated by groups of components, rather than single
components.

If we have a GUI abstraction, we could detect what libraries exist
at build time, and couple those into the system, or ask if the
person wants to install others.

If I have understood the ideas correctly, this seems to tie in with
the ideas on PragProg about "boiled frogs" and "It's Just a View", and
the ideas in Design Patterns about Model View Controllers -- keeping
code detached from the display methodology.

I don't think this layer needs to be "thick" so it should be a light
computational burden on the GUI kit below.

Is this sensible, or have I just proposed a cycling course for fish? :-)

	Hugh
	hgs / dmu.ac.uk