The wrapper project

[Joe Armstrong]

On Thu, 21 Aug 2003, Vlad Dumitrescu wrote:

> ----- Original Message ----- 
> From: "Joe Armstrong" <joe@REDACTED>
> >   I'm back .... (been on holiday)
> 
> Welcome back!
> 
> >   I would like to propose the construction of a series of "wrappers" -
> 
> Very interesting idea.
> 
> >   I am  currently pursuing this idea.  My first component  should be a
> > control wrapper round  wxWindows so we can do GUI's -  NOTE my view is
> > that  the GUI  is  itself a  *component*  which is  isolated from  the
> > application which should be another component.
> 
> Looking forward to it :)
> 
> >   NOTE the image component ONLY displays the image and has NO GUI - the
> > GUI must be done by the GUI component (which I am trying to write :-)
> 
> I think I don't really understand what you mean.


   Like this:
                                                         +----------------+
   +-------------+  socket  +----------------+  socket   | +------------+ |
   | Generic GUI +----------+ Erlang process +-------------+ generic IO + |
   +-------------+          +----------------+           | +------------+ |
							 |       |        |
							 | +------------+ |
							 | | Image      | |
							 | | canvas     | |
							 | +------------+ |
							 +----------------+

   The generic GUI is just that. A GUI which is controlled by the
Erlang process. The Erlang process sends it {mk_window, ...}
{add_button, ...} events.

   Events in the GUI resut in {button_pressed, ...} message being sent
to Erlang.

   I assume the GUI does not know how to display an image.

   The Image component *only* knows how to display images and is commanded
by {display_image, ...} {resize, ..} messages from Erlang.

   All three components could in principle run on *any* machine.

   (and Yes the GUI probably can display images - that's not the point
The Image component could be anything (a music player, a movie player etc.)

  Most Apps are  not structured like this - the GUI  the logic and the
application engine are mixed into  one glorious mess which runs in the
same  address space  - so  a bug  in one  component crashes  the other
(innocent components)


> 
> If the image component can display something by itself, then it has a GUI (even
> if it's a dumb one).

  I don't  consider it a GUI only  a display. It has  no "buttons" and
can only display stuff.

> What would be needed here is a "remote canvas" created by
> the GUI component, and on which the application could draw. Alternatively, the
> application would describe for the GUI what to be drawn via the protocol - and
> we get the X basic setup. Or one could split into three layers, according to the
> Model-View-Controller pattern: the application knows how to manipulate the
> binary bitmap, the view knows how to display it, and the controller... well, it
> coordinates :)

I don't think it's Model-View-Controller

How about the

TV-Zapper-Controller model

We have a TV which talks to a Controller
We have a programmable zapper (remote control) which talks to the controller

The controller can cause arbitrary buttons/entries etc to appear on the
zapper.

Messages from the zapper go the controller and result in commands going
to both the zapper and the TV.

/Joe

> 
> regards,
> Vlad
>