From: "Albert L. Wagner" <alwagner@...>
Date: 2001-08-15T23:19:10+09:00
Subject: [ruby-talk:19778] Re: The GUI poll is in, and the results  aresurprising

You've brought up the second of two separate issues: 1) the GUI
code and 2) the layer between the GUI and Ruby.  Both are
important.  And the second should be the easiest to change.  That
middle layer requires someone proficient in both Ruby and the
underlying GUI.

Lars Christensen wrote:
> 
> On Wed, 15 Aug 2001, Dave Thomas wrote:
> 
> > Fox, the new kid on the block, consistently held a narrow lead over
> > GTK.  Surprisingly, Tk never really made a showing, despite being
> > bundled with Ruby on both Unix and in the Installshield Windows
> > distribution.
> >
> > So, what started as a poll for fun has actually raised some real
> > questions. Should be switch to bundling FOX with the Installshield
> > distribution? Should we be trying to find a way to make it easier to
> > include Fox with Linux versions (that 30 minute compile still scares
> > me).
> 
> Please don't forget what Ruby is all about in this discussion! I think
> that the basic principles and idioms of Ruby should be respected in the
> GUI that is made the "standard" for Ruby.
> 
> Enjoying coding in Ruby can come to a halt when you are faced with a GUI
> API that isn't Ruby's way of doing things. My take:
> 
> Tk isn't object oriented, at least not with Ruby Syntax.
> 
>         TkButton.new {
>           text 'Hello, World!'
>           command 'exit'
>           pack('fill'=>'x')
>         }
>         Tk.mainloop
> 
> What is objects? Where is my object representing the window on the screen?
> Where does the 'text' and 'command' methods come from?  What odd
> semantics. This may be intuitive if you know the Tk semantics, but it
> isn't Ruby.
> 
> FXRuby is IMO only a wrapper around a reasonable C++ Gui interface. It
> isn't Ruby either. E.g. to declare message identifiers:
> 
>         ID_CANVAS, ID_CLEAR, ID_LAST = enum(FXMainWindow::ID_LAST, 3)
> 
> That is plain C++ style (or something) coding. Too many techinal
> detais (not VHLL). Why not the Ruby way?:
> 
>         identifier :ID_CANVAS, ID_CLEAR
> 
> What about:
> 
>     @contents = FXHorizontalFrame.new(self,
>       LAYOUT_SIDE_TOP|LAYOUT_FILL_X|LAYOUT_FILL_Y, 0, 0, 0, 0, 0, 0, 0, 0)
> 
> Yuck! What was that 5th zero about again?
> 
> Gtk, I think, it a little cleaner about mapping concepts to the Ruby
> Language. I can do "class MyApp < Gtk::Window". Gtk/Ruby uses
> assignment methods so that you can do "@buttonbox.border = 10". This is
> very intuitive, and its the Ruby way. It also has very few methods
> that takes more tthan 1 or 2 arguments. Most things are configured
> through methods.
> 
> Gtk is ported to windows. The Ruby/Gtk/Windows combo should be possible
> with a little effort.
> 
> I wish for a GUI API that:
> 
> - Assumes defaults for everything except the basic requirement. Everything
> else should be setable through methods. E.g. Label.new('Press me').
> Border, color, font, and everything else should not be arguments to
> constructors. Never.
> 
> - Uses Ruby concepts to the full extends. No win.set_border(40) when
> you can handle it with win.border = 40. Use of attribute declerator
> methods whenever applicable in the line of attr_*.
> 
> - Allows inheriting classes to create windows or other widgets with
> special keyboard/mouse handling.
> 
> For now, I think Gtk is the best canditate (having not tried Qt). In any
> case, I want pure ruby style interfaces before portability.  With matz
> have designed such a great language, it would be a shame to waste it on
> ugly APIs.  A lot of Java's success comes from it's coherent,
> comprehensible and consistent API. There is "one way" to do things, and
> they stick to it.  I'd like the same thing to happen in the Ruby world.
> 
> --
> Lars Christensen, larsch@cs.auc.dk

-- 
"It requires wisdom to understand wisdom:
 the music is nothing if the audience is deaf."
 - Walter Lippman