[ruby-talk:23390] Re: GUI / was [ANN] RubyInRubyParser 0.1-pre-alpha

This code would work just at well without any complex builtin support for
calling multiple items of code.

def widgethandler
      Selectedtool.onwidget
end

when the user selects a widget

Selectedtool = selectedwidget

or perhaps

def widgethandler
      Selectedtool.call
end

Selectedtool = proc { some code ...... }

Or have I missed something?

----- Original Message -----
From: "Nat Pryce" <[e-mail]>
To: "ruby-talk ML" <[e-mail]>
Sent: Friday, October 26, 2001 2:34 PM
Subject: [ruby-talk:23389] Re: GUI / was [ANN] RubyInRubyParser
0.1-pre-alpha


> 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" <[e-mail]>
> To: "ruby-talk ML" <[e-mail]>
> 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:[e-mail]]
> > > > > 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
> > > > >
> > > > > --
> > > > > -------------------------------------------------
> > >
> > >
> >
> >
>
>