From: Nat Pryce Date: 2001-10-26T10:34:25+09:00 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" To: "ruby-talk ML" 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 > > > > > > > > -- > > > > ------------------------------------------------- > > > > > >