----- Original Message ----- 
From: "Tom Sawyer" <transami / transami.net>
To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
Sent: Tuesday, July 30, 2002 10:40 AM
Subject: Re: [OT] Re: GUI's and the Rouge, Part III (yes, finally) 1/2


> On Tue, 2002-07-30 at 08:43, Hal E. Fulton wrote:
> > I've been experimenting with the "pluggable" UI concept.
> > Since I don't understand MVC that much, I'm probably
> > reinventing the wheel (or rediscovering fire). But it's 
> > an interesting concept to me.
> > 
> > Anyone who wants to discuss it, speak up.
> > 
> > Cheers,
> > Hal
> 
> Hal, i gots to know more. need to know about your plugable work. i've
> done work on a couple such designs myself. what have you come up with so
> far?

Oh, nothing earth-shattering. I have a couple of apps I'm
playing with, and putting all the user interface stuff
into modules.

Have come up with some simple concepts and rules of thumb.
For example, there is a kind of "one-way coupling" of the UI
module with the "core" of the app. That is, the UI methods
are allowed to know the details of the app itself, but the
app need not (is not allowed to) know the details of the 
UI code.

Except: The UI code must have a simple common interface for
whatever GUI or TUI is implemented. Typically I have 
implemented this as fairly high-level routines like 
ui_prompt_user_yes_no(msg) which e.g. will display a msg and
get a yes or no response. In Tk or Fox I use buttons; at the
simplest level I use puts and gets. 

I use a ui_init for whatever initialization needs to be done.
In pure text, this may be empty.

I use a ui_eventloop that translates in a straightforward way
into Tk or Fox code. In pure text form, it can simply call a
method that displays a menu and/or gets a command via gets.

Within each module (in the methods), I can reference data 
members as needed and they will spring into the existence in 
the class into which I've included the module. These can be 
used to store info related to Tk or Fox widgets or whatever 
is needed. It's a slight increase in coupling, but if the 
"core" code doesn't know about the new member variables (and 
it shouldn't), then it won't normally be referencing them. 
There is, of course, the chance that the same name will 
accidentally be used for a "core" variable and an "interface" 
variable. Since I'm writing both, this doesn't usually happen 
to me. You can reduce the chance by a prefix like "ui_", i.e. 
@ui_root or whatever.

Incidentally, there was some discussion about whether people
actually ever write an app with a text interface and add a 
GUI later. I've been trying that with these two apps, and I
like it a lot so far. It helps with SOC (separation of concerns)
and it makes the interface easier to switch around.

> 
> p.s. love the book, just picked it up a few days ago. thanks.
> 

Thank you.

Hal