I would prefer widgets to maintain lists of closures that are called when
events occur.  That way it's easier to call multiple objects when events
occur.

One of the most awkward aspects of Tcl/Tk is that widgets would only call a
single command when an event occurred.  This makes it hard to temporarily
register additional code to be invoked in response to events, and then
unregister that code again.  E.g., you would want to do this in a graphical
editor with multiple tools, as the user changes the currently selected tool.

Cheers,
        Nat.

----- Original Message -----
From: "Avi Bryant" <avi / beta4.com>
To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
Sent: Thursday, October 25, 2001 11:54 PM
Subject: [ruby-talk:23371] Re: GUI / was [ANN] RubyInRubyParser
0.1-pre-alpha


> On Fri, 26 Oct 2001, Eli Green wrote:
>
> > I never understood why Swing was so slow. I do know, however, that Swing
is
> > VERY powerful, much more than people realize. Anybody who's ever written
a
> > Java application with WebObjects will know what I'm talking about.
> >
> > However, a native Ruby GUI could be just as powerful, and a fair bit
sexier!
> >
> > For example:
> >
> > window = Window.new
> > button = Button.new
> > def button.activate
> > print "Click!"
> > end
> > window.add(button)
> > window.run
> >
> > Or something like that. The point is that Ruby has an event model
already
> > written for us .. just redefine that instance's method!
>
> An alternative model I played around with involved linking widgets to
> WebObjects or IOWA-like property paths (is this how JavaClient works?
> Never used it).  So a list widget would be bound to table.people, and
> would put its selected item into, say, selectedPerson... you would then
> have a text input field bound to selectedPerson.firstName, so that when
> the selection in the list box changed the field would automatically update
> itself.  It's a very powerful model, and I implemented a decent version of
> it once in Objective-C and Gtk, but it would be cool to see in Ruby as
> well.  The drawback is that it requires a lot of complex Observer logic to
> get all the syncing right.
>
> One thing I dislike about using singleton methods is that they don't play
> nearly as well with something like Glade or other GUI builders - I prefer
> to have more indirection between the view and control layers.
>
> Actually, thinking about it, what you're describing seems very like
> Morphic.  Have you looked at Self or Squeak at all?
>
> > Another very cool thing this could lead to is something like this:
> >
> > PersonFactory = Struct.new("Person", :first_name, :last_name, :iq)
> >
> > window = Window.new
> > table = Table.new
> > table.header = ["First Name", "Last Name"]
> > table << PersonFactory.new("Joe", "Slopchuck", 210)
> > table << PersonFactory.new("Some", "Guy", 160)
> > table << PersonFactory.new("Eli", "Green", 10)
> > def table.data_for_row(row)
> > return [row.first_name, row.last_name]
> > end
> > window.add(table)
> >
> > So table would look something like:
> >
> > +------------+-----------+
> > | First Name | Last Name |
> > +------------+-----------+
> > | Joe        | Slopchuck |
> > | Some       | Guy       |
> > | Eli        | Green     |
> > +------------+-----------+
> >
> > Doing this:
> >
> > table.selected_object
> >
> > Would return the actual Person object that was inserted previously,
giving the
> > entire environment a very OO feel. The same could be done for ComboBoxes
and
> > Lists and such ... a reference to an object would be stored by the
widget, but
> > the display would be determined by the re-defined format method call.
> >
> > I'd be willing to take a stab at doing something like this using SDL or
some
> > other platform-neutral framebuffer lib. Anybody else interested?
> >
> > from Rich Kilmer on 2001-10-26 at 06:19:59:
> > > I wrote a sophisticated lightweight component framework on Java
(before Swing) that was very fast.  Of course, writing it in a "higher
level" language adds overhead, but not as much overhead as bad design ;-)
If you could have low-level primitives written natively and layer higher
level constructs with Ruby, I think you could build a very responsive UI.
> > >
> > > -Rich
> > >
> > > > -----Original Message-----
> > > > From: markus liedl [mailto:markus.lado / gmx.de]
> > > > Sent: Thursday, October 25, 2001 4:23 PM
> > > > To: ruby-talk ML
> > > > Subject: [ruby-talk:23350] Re: GUI / was [ANN] RubyInRubyParser
> > > > 0.1-pre-alpha
> > > >
> > > >
> > > > > having a native window with a canvas which Ruby draws on using
> > > > the BitBlt
> > > > > operation.  From there we can think about a GUI toolkit like
> > > > Squeak's, and
> > > > > other things like that.
> > > >
> > > > matju, and experiences with Java Swing will tell you that this
solution is
> > > > not fast, and will never be. I was surprised, but Swings slowness
does not
> > > > depend on the hardware it runs one, it's just slow. (I have
> > > > impressions from
> > > > using Swing on a k6-2 350,  P3 650, athlon 1.4)
> > > >
> > > > matju's ideas say: get compatibility by the X11 protocol ( which
> > > > may not be
> > > > what windows-guys like).
> > > >
> > > > It's waste of time to copy Java Swing for Ruby.
> > > >
> > > > Surely, it's a nice occassion for you to learn how a certain chip on
your
> > > > graphic card is doing BitBlts, but for serious work, let it do this
chip.
> > > >
> > > > markus
> > > >
> > > > --
> > > > -------------------------------------------------
> >
> >
>
>