GUI's and the Rouge, Part 1

i just discovered Rouge. a very ambitious project to say the least.

it is interesting that i have just now come across Rouge as i have just
given up on effectivly attempting to do the very same things that Rouge
hopes to accomplish. it is disappointing. i put numerous hours into the
project and personally am very saddened that i felt that i must abondon
it. but i came to a number of realizations that make such a project,
while not impossible, exteremly difficult, and doubtfully worth the
effort.

for starters there is the GCF problem. to be truly effective in the
attempt to offer native support for a variety of platforms (QT, GTK+,
win32, Cocoa, to name the major 4) the Greatest Common Factor must be
the base line for the widget set. this means that any widget one kit
supports that the others do not, a "composite" widget must be created
for each out of available widgets to achieve the same functionality. in
effect then you end up with a huge number of widgets to create and
maintain. were talking about a very very large project!

secondly, one then must consider cross-functionality. if widget A in
toolkit X does not function the same as widget A-ish in toolkit Y, then
how will one map the two? at this level it will probably be very
difficult, most likely impossible, to "composite-out" excatly the same
functionality. thus some feature of widget A and/or A-ish are bound to
be unavailable.

even if you deal with these first two daunting tasks, you then come to
the issue of bindings (this is actually related to the second problem
but deserves its own mention). each toolkit exposes its bindings
differently. a perfect mapping will again be impossible, but worse the
code complexity of creating a single binding model (the controller?)
that then effects the underlying native binding model in a consitent
manner will be a major coding endeavor, if it is even possible. again
somethings are goign to have to left out. this alone is a serious
project in and of itself!

finally, in my opinion, the most ruby-esque/POLS gui should be able to
mixin, such that the mixed object automagically interfaces with the gui.
that would be THE feature of a dream ruby gui. but it turns out to be
all but impossible. first, because most gui toolkits take control of
execution (a la Tk.mainloop) all subsequent processing has to be handed
over via the passing of pre-built closure procs. this simply make for a
lack lust design neccessity. your subsequent applications are going to
be full of a lot of ugly code. but what makes the hope of automagical
communication between ruby object and gui even more daunting is the fact
the =() is not a ruby method or to be more proper, there isn't a
determinate syntatical distinction between assigning a variable which
becomes a new object versus simply replacing the value of that object.
there is no way then to callback on reassignment. thus you are forced to
create seperate constructs for effecting your object's instances
alongside the gui's.

so that is my assesment of the hopes and dreams of the rouge project.
while not impossible, it is a task of such huge proportion that it would
take many many man hours to complete, and even then it will not be
ideal. its too bad, such a thing as Rouge would be a developers dream
indeed.

but do not give up hope! i will follow up this post later with what i
think may be a much better approach...

~transami



-- 
~transami

  _(")_  dobee dobee do...
   \v/  
   ^ ^