Separation of gui from "real work"

Ruby
1

This is not a ruby specific topic but since there were some definite
opinions expressed about systems of writing GUIs in a recent thread, let
me ask it here.

Is there a practical program architecture for separating the gui portion
of a program from the part that does the “real work”? Or is this just a
high flown idea that is rarely practical?

Conceptually, one could write “the real work” part of the program as a
kind of state engine that is driven by an “interface” which provides
inputs and receives outputs. Various “interfaces” could be written.
For example, one might use console I/O, another might use WxWidgets,
etc. Perhaps if the “real work” part of the program is not that hard,
this is overkill. But, for example, when I want to try to write some
fairly hard numerical problem (and when I am unsure of whether my ideas
about it are sound!) the last thing I want to do is start thinking about
how to design a gui interface for it. It goes faster to read the inputs
from a file and print the outputs on the console. But, on the other
hand, I don’t look forward to separating the “real work” from a
gui-to-be-written-in-the -future-in-some-as-yet-to-be-determined-system
by writing the file-and-console interface. Perhaps this seems tedious
because I haven’t had enough practice writing interfaces of either kind.

There are approaches that pride themselves in binding the gui tightly
together with the application without any intermediate interface. For
example, Fox lets you bind a “real work” variable to something
represented in a gui. I think in this point of view, you treat the
“real work” as a collection of services (not as any kind of state
engine). Then you use the gui as the glue that puts them together into
a useful machine.

2

A couple of links that may help:

3

Stephen T. wrote:

This is not a ruby specific topic but since there were some definite
opinions expressed about systems of writing GUIs in a recent thread, let
me ask it here.

Is there a practical program architecture for separating the gui portion
of a program from the part that does the “real work”? Or is this just a
high flown idea that is rarely practical?

You need to look into a concept called MVC - it stands for
Model/View/Controller.

The specifics vary from language to language but essentially, this
technique carves your app into three sections:

The MODEL defines your data structure. This could be the way it’s
stored in a database, or the file format if you’re writing to a file.
Ideally, you should be able to have as little as possible of the
implementation-specific nature of whatever you use to be exposed. For
example, if it’s a music management app, don’t have a method called
“executeSql” exposed outside of the Model, because maybe you also want
to store it in a file where SQL is not appropriate. Instead, implement
methods for all the different tasks you might want to perform - adding
songs, getting lists of songs by a particular artist, and so on.

The VIEW is the user interface and all the associated logic for that.
If you want to show the info in a tree view, like Windows Media Player
(say, Artist>Album>Song), then you’d build the tree here.

Finally, the CONTROLLER is the bit that handles all the complicated
logic. Building a random playlist might happen in the CONTROLLER, for
example. There is always some overlap, and there is necessarily some
links between the different modules, but these should be kept limited
and tightly controlled so that you know where to go if you want to swap,
say, from an SQL database to a proprietary file format.

A good example in Ruby is Rails, which also adds a HELPER section. This
technique (as evidenced by Rails’s HELPERs) is not set in stone, but
it’s a basis for you to build your apps on.

Hope that helps

4

The original post was a pretty general question. MVC is certainly
one approach
but it still embeds the ‘real work’ in the GUI application albeit via
a nice
internal structure.

Yeah, my post was intended to suggest a way he could seperate the

Another thought is that the ‘real work’ is done via some sort of a
server
application with an API that is accessed from clients via inter-process
communication of some sort. Think of the separation of functionality
between a mail reader application and the back end mailbox server via
IMAP or POP.

I disagree - a client may do some ‘real work’, and a server may have a
certain level of GUI (such as config and administration stuff). And
even if it’s not like that, client-server is not appropriate in every
situation - often I want an app that just runs locally.

Take my music manager example - do I really need a server application to
store my song data? When I want to add a song, should I really need to
start the server and then the client just to do that? I don’t think so.

So a lot of apps (the majority, IMHO) could just be simple little things
that run on my PC whenever I need them. In that case, how do I seperate
the GUI from the server? Well, you need an internal structure that does
that.

Stephen, do you want to seperate your GUI into a completely seperate
application, or just a different module in the same application?

5

On Apr 7, 2006, at 8:21 AM, John wrote:

high flown idea that is rarely practical?

You need to look into a concept called MVC - it stands for
Model/View/Controller.

The original post was a pretty general question. MVC is certainly
one approach
but it still embeds the ‘real work’ in the GUI application albeit via
a nice
internal structure.

Another thought is that the ‘real work’ is done via some sort of a
server
application with an API that is accessed from clients via inter-process
communication of some sort. Think of the separation of functionality
between a mail reader application and the back end mailbox server via
IMAP or POP.

It might be worth exploring the c2.com website which has lots of
discussion on
software patterns. You might start at http://c2.com/cgi-bin/wiki?
ModelViewController

Gary W.

6

On Apr 7, 2006, at 11:04 AM, John wrote:

certain level of GUI (such as config and administration stuff). And
even if it’s not like that, client-server is not appropriate in every
situation - often I want an app that just runs locally.

Huh? I simply suggested that not all problems need/should be solved
with MVC
and provided an example as well as a pointer to a repository of software
patterns. I wasn’t trying to say that MVC wasn’t useful at all. It
can even
be part of the GUI client app talking to the non-gui server app that
is doing
the ‘real work’. There is nothing to agree or disagree with unless
you think
that every peg should be shoved into the MVC-shaped hole. In that
case, I disagree.

Gary W.

7

unknown wrote:

On Apr 7, 2006, at 11:04 AM, John wrote:

certain level of GUI (such as config and administration stuff). And
even if it’s not like that, client-server is not appropriate in every
situation - often I want an app that just runs locally.

Huh? I simply suggested that not all problems need/should be solved
with MVC

Ah, no argument from me there. Sorry I just misunderstood your post as
saying “don’t use MVC - use a client/server topology instead”. If
that’s not what you were sayingm then we’re all good.

8

John wrote:

You need to look into a concept called MVC - it stands for
Model/View/Controller.

I’ve looked at that in the sense of reading about it. But general
concept isn’t so specific about separating the “view” from the other
parts. As an example of a specific issue, suppose the “view” has a
window with fields X,Y, Z. When the user changes Z, we want X and Y to
be updated. I suppose the idealistic approach would be for the view to
tell the controller to update Z and inform the view about the new X and
Y. The server-client or “communicating processes” implementation of
this would make it clear that the “view” is, in some sense an
independent entity. But one could take the single-process approach and
made the “view” a gui which treated the model and controller as a set of
functions to be called at appropriate times.

The “communicating processes” way seems to carry a lot of overhead with
it. On the other hand, I’ve thought of schemes with even crazier
amounts of overhead. When I think about a system of gui’s abstractly it
seems to consist of “windows” and in these windows are various visible
things. Some are passive and merely display information. Some take
inputs. Others can be activated and cause further windows to appear.
So I think of the abstract architecture of a gui as something like the
typical display of a tree (like the Windows registry keys). The folders
are abstract windows. I ignore anything about their position, size etc.
I merely think of them as an abstract data structure. Each is either
“active” or “inactive”. The things on them are not specified by any
appearance (like “button” or “radio dial” ) or any geometrical location
in the window. They are merely described by the type of data they
display or input. So the idea would be to create the abstract
architecture of a gui. Then one could interface various real gui’s with
this to implement something useful. For example, in one interface the
field that displays X and Y might be a text field, in another interface
it might be a two thermometers, etc.

This is such a nice concept but it also seems like so much trouble that
I doubt anyone will every bother to do it.

It also does not solve what I find most irritating about the coding of
guis. Namely that it is laborious to make changes in what component is
a child of what other component. One thought for a gui designer is
simply to build into the gui writing system the feature that when a
certain global variable, say, “DESIGN_STAGE” is 1, then each component
can be selected (perhaps by the awkward ALT-TAB way of moving focus) and
caused to pop down a little menu that says “Edit Me” and offers the user
options to modify it. It should be easy to change things that are
parametric. For example to change the size or color. But it would be
harder to change the type of the component (say from button to check
box). It would be very hard to implement moving a component from one
parent object to another parent object. As far as I can see, in the
current systems for writing GUIs, this would amount to a recode and
compile on-the-fly. I suppose this is what GUI design programs must do,
but a self-designable gui system would be doing this to itself. I
don’t know what computer science it would take to make moving child
objects from parent to parent possible, but I would like to see a system
of writing GUIs where this was easy (thus making the dream of the
built-in gui designer possible).