Phil Tomson wrote:

> 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.

I'll check that out when it is available.

> 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've tried before to separate gui logic from the rest of the app's
logic. It has not worked well for me yet, though I approve of it in
principle.

Here I'm simply not separating those.

> 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.

That's pretty interesting. I've never yet conceived of a state-
machine approach in that kind of situation.

If I were you, I'd put together a working example (not too complex,
not too simple) and write an article about it. Bet Dr Dobbs would
go for it.

Cheers,
Hal