From: Tom Sawyer <transami@...>
Date: 2002-07-21T02:00:47+09:00
Subject: GUI's and the Rouge, Part II

in part one of this message i mention the problem of non-POLS and
ugliness when it came to hand coding a GUI interface. follow this link.
it is example code of the Rouge's utopia:

http://www.rubyide.org/cgi-bin/wiki.pl?RougeArchitecture/Alpha 

i can honestly say this code is probably better than any i have ever
seen, but i'm sorry, it's still just dosen't look like my idea of gui
utopia. it is still a traditional approach, albiet very innovative in
its use of ruby's OO and iterators, it nonetheless follows the same
overall design characteristics of other tools: defining each and every
widget, designating *content* and style, their coorelation, and binding
procedures before passing off execution control (app.controller.start)
to the gui engine. but, i hear you thinking, "what other way is there?
that's just how it's done!" well, i emphisized content above because its
the key to a better approach. we can get a taste of this by looking
amrita:

http://kari.to/amrita/sources/docs/QuickStart

the beauty of amrita lies in the fact that the data which is to appear
in the end result contributes to its design. thus, in part, the layout
does not have to be specified because the data itself designates it. the
end result is cleaner leaner code. in effect amrita has done what OO
design is intended to do, it has given precedence to the data model. 

although amrita is a unidirection html/xhtml templating system, her
principles just as easily carry over to guis. arbitrarily, as
programmers, we can think of it like this: instead of widget.displays(x)
we get x.widgetized. let me provide a mock code fragment to help
clearify. we'll call our imaginary gui toolkit, RougeDuex.

  require 'rougeduex'

  class MyClass
    attr_accessor avar
    def initialize
      @avar = "" 
    end
  end

  myobj = MyClass.new
  myobj.avar.extend RougeDeux::WidgetFactory(:Label)

  mywin = RougeDuex::WidgetFactory(:Window).show
  mywin.embody {
    pack myobj.avar, RougeDuex::TOP
  }

  myobj.avar = "Hello, World!"

and just like that we have a window with a label in it greeting us. 

you might notice something a bit odd about this very simple example: the
window was displayed prior to the label being added. this is a key
point. by retaining execution, such that the gui is a spawned processes,
we retain the ability to modify it "on-the-fly". just think of all the
neat tricks we can do with that! no longer are we limited to just the
event model of the gui's engine. morever, notice that the class
definition is completly clean. there's no mention of RougeDuex anywhere
in it, nonetheless it is direclty linked to our gui. should avar change
for any reason, so will our label. and if avar were a text entry field
or any other input widget, instead of a label, avar would automagically
reflect that input.

you may wonder how other aspects of avar as a label get designated. well
since avar was extended to be a label it gained a few things that allow
us to do that: myobj.avar.style={:color=>'red'}, for example. no
problem!

also one might be concerned about performance with such dynamic
rendering, since anytime one changes a variable the gui requires
refreshing. well, a transaction model can help with that were it is
essential.

so there's the ideal, my friends. i am sure certain elements of the
current Rouge project could be carried over into this, and i think the
end result would be the easiest, most intuitive and fun (like ruby!) gui
to ever have the priviledge of being coded by you ;-)

in the last part of my series (don't ask me what posessed me to do this,
i don't know!) i'll go into the possabilities of implementation.


~transami

  _(")_  v man
   \v/  
   ^ ^