From: ptkwt@... (Phil Tomson)
Date: 2004-04-08T01:54:19+09:00
Subject: Re: Idea: Simplified GTK

In article <4073C9EC.7020400@hypermetrics.com>,
Hal Fulton  <hal9000@hypermetrics.com> wrote:
>Here's an idea. I've begun implementing it.
>
>Tell me why it's dumb, or what its shortcomings are.
>
>Put all your logic inside an App.logic (which will get called from
>App.run and wrapped with the stuff it needs). Afterward, call App.run
>itself.
>
>You automatically get one toplevel window, called @main in App.
>Everything in App.logic defaults to this as a container.
>
>When you create a container, you put a block on the constructor. Any
>widget (container or other) created in that block will belong to the
>current container. So the nesting of the block structure reflects the
>nesting of the containers.
>
>When you create a non-container, you put a block on the constructor.
>It will be associated with the "default" (most common) message for
>that widget.
>
>Here's some code. It works, for what it's worth.
>
>     require 'ez-gtk'
>     include EZ_GTK
>
>     def App.logic
>       @main.title = "My window"
>       @hb = HBox.new do
>         @vb1 = VBox.new do
>           @btn1 = Button.new("Do it") { puts "pressed btn1" }
>           @btn2 = Button.new("This too") { puts "pressed btn2" }
>         end
>         @vb2 = VBox.new do
>           @btn3 = Button.new("Third button") { puts "pressed btn3" }
>         end
>       end
>     end
>
>     App.run
>
>Please comment on this before asking to see ez-gtk itself.  ;)


This is exactly how the FLTK ruby bindings I'm using work (unfortunately 
they're not publicly available yet) except that instead of defining a 
class method we actually define a class and this is done in the 
constructor for that class.  It is a nice way of doing things.

However, your naming convention seems confusing to me.  You're calling 
this method App.logic, when in reality this is App.GUI since this is where 
you're actually defining your GUI elements.  App.logic, (again it seems to 
me) should be something like a state machine that responds to events that 
come from the GUI. 

I guess I'm sensitive to this  since the app we're currently 
developing needs to work both as a
GUI and as a console app (depending on the environment it's running in) so 
I'm trying to seperate the GUI elements from 
the underlying logic as much as possible.  Basically I have a state 
machine that encapsulates all of the logic and then I can plug in 
different front ends (or at least that's the goal, it's not all there 
yet).  I use Observable as a means of passing events back and forth 
between the state machine and GUI.
 
Phil