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

In article <40744628.1090309@hypermetrics.com>,
Hal Fulton  <hal9000@hypermetrics.com> wrote:
>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.

I hope it will eventually be available.  These particular RubyFLTK 
bindings were developed by someone else in the company where I'm 
contracting.  Theoretically, they could be released, but there is
probably some paperwork to get through to clear it with the Legal folks.
It probably won't happen very soon, unfortuneately, it's too bad because 
they're quite nice to work with and they've even got the FLUID GUI-Builder 
emitting Ruby code.


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

I started out in hardware design.  In hardware we use state-machines 
everywhere so they just seem natural.  Of course in software you can be 
much more creative in the types of state-machines you develop.  I often 
wonder why it's not a more commonly used design pattern.

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

Hmmm.... That might be worth a try.  Thanks for the idea.

Phil