a bit of an intro: my original thought on the matter of making a
rubyesque gui api was to use the power of mixins to make objects
automagically linked to a gui form. while that still has some appeal,
massimillano mirra and ned konz pointed that this really meshes the gui
to tightly with the objects them self, resulting in poor SOC (seperation
on concerns) and limited code reuse. i thought about the matter in depth
and decided that they were right. there would be great advantage, if
done well, form creating an intermidiary beteen application objects and
the gui they are to interact with. so i set my sites on that goal and
reworked my ideas --the result looks quite promising. thank you
massimillano and ned.

but before i get into the nitty-gritty of ruby code. lets back up a
attack some over all architecture issues.

it was stated that a main goal of Rouge was to create a cross-compatible
gui api that "boiled down" into the native gui of each platform. in my
first post on these matters, i pointed out how ungodly difficult that
would be (as i had been trying to do that myself). in the end either you
left to "patch" your app for each platform or you simply have to give up
the features that they hold in common (at best). it really is simply too
much of pain to create such an system, not to mention maintaining it as
those underlying native api change. yet the goaol os a native look and
feel is not unachievable by other means. the solution is simply a matter
of using an underlying gui engine that is sufficiantly themeable. since
all the major gui's are now themable themselves, we simply need to code
a theme manager that can import the themes of those other guis. we need
not use their underlying api, only their look and feel! so that's what
can be done to solve that dilemma: use a sufficantly themeable gui api
and crreat and Themes and Behaviors Manger to emulate the look and feel
and even draw upon the native theme configuration files. this is a much
managable task then trying to channel down to the native guis
themselves. the only trick of course is finding that themeable gui api.

well, as things often are, it's a tale of two. my first hope lied in a
gui api called ParaGUI:

http://www.bms-austria.com/projects/paragui/

this is a nice gui api based on SDL which is in turn based on OpenGL. it
is a little immature as of yet, but can be themed. but just to be sure i
looked around a bit more. i filter through a number of others, GLUT and
GLUI come to mind, but then i found something all together better. well,
that's is at least how it looks. you never actually knwo until you get
into it, but even so we could always fall back to ParaGUI. but what i
found wasn't labled strictly as a GUI, becasue it ws so much more. it
was a complete game sdk! but had all the standard gui widgets that one
could want but a whole lot more to boot. and yes, it was themeable. a
god send! check it out:

http://www.clanlib.org/documentation/ClanLib-0.7/Reference/html/classes.html

now were cooking. one last issue: execution control. rich kilmer
mentioned the possibility of using sockets: "This could be addressed
(without adding native threads to Ruby)...such as having another process
that presents and controls the UI and communicates to the Ruby process
via a socket...like X." and i think too that this is a fantastic idea.
so that's the final piece and we end up with basically this:

  +------ +--------+              +--------+----------------+
  | A    ~| Ruby   |     DRb?     | Ruby   ; Ruby | ClanLib |
  | Ruby ~|  GUI   |<------------>| GUI    ; Wrap +---------+
  | App  ~| Client |    yaml?     | Server ;      | Themer  |
  +------ +--------+              +--------+----------------+

now the communications layer can be optional, that's now big task to
have it be able to work both ways, so were speed made be extra critcal
it could be left out. but that's the over layout. and i think its a
design that that is well worth the effort to create.

i'm going to take a break now before going into the ruby code: but i
have created the beginnings of what i'm calling GUtopIa. more in a
bit...

~transami