Musings on an Erlang GUI System

[Jay Nelson]

Joe Armstrong:
 > What I'd like to see is *one* page description language that can be
 > used for making GUIs AND pages of printed text.

Chris Pressey:
 > I think the only decent way to define a UI is to *not* define a UI.
 > The UI should follow naturally from richly-defined data types.
 > Don't do *anything*, just define your data right, and let the data define
 > the UI.

There have been various other things mentioned, which at times seem
to conflict, but I think all these issues are independent of one another
and can be combined in a compatible way.  To me the main points are:

1) The desire for one data format
2) Having exactly the same output on screen and paper
3) Interacting with data in a natural way
4) Having a responsive UI
5) Adaptive presentation based on the task at hand

The paper issue is a problem until the resolution is better (Apple is up
to 200 dpi now, though) but the pdf / postscript approach works well
in approximating the look on screen and on paper.  I think on screen it
is more important to interact with the data and have data change in
realtime rather than being static like a document.  Liveness also means
having the UI provide feedback to the user with sounds or visual clues
to help direct the user's actions.

erlang implements proxies really well.  A process that works on behalf
of the user makes it possible to script a series of actions or program
a parallel set of UI adjustments that can be triggered by a single gesture
with the mouse.  Likewise, if data were represented as processes, they
could interact with proxies that represented them on screen or on paper.
Changing the viewpoint or format is just a matter of connecting the data
process to a different proxy server.  This fits neatly with the X server
approach as Joe pointed out.  It also means that the user can dynamically
change the display, or the data can dynamically change the display,
in complex ways but with simple commands.  Something more akin to
the Model-View-Controller approach, but just as others pointed out about
OO vs. Concurrency, the implementor can choose how much or how
little of the MVC approach is necessary by including or excluding the
appropriate cooperating processes.

jay