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