The wrapper project

Joe Armstrong joe@REDACTED
Thu Aug 21 15:54:17 CEST 2003

On Thu, 21 Aug 2003, Vlad Dumitrescu wrote:

> Hi,
> >    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.
> Yes, that part was clear even to me :)
> >    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.
> It is here I lost the track. To me, "displaying something" is tightly connected
> with a medium on which the resulting image will be visible. 

Yes - in my model only the X component knows how to display a X.

Here X = jpeg (it might have been (say) an mp3 file).

> Only the GUI has the
> physical ability to actually show something on a screen (or similar).

  To make  it clearer I'll talk  about music instead of  images (I guess
GUIs dont's understand how to play music :-)

  I had intended the generic GUI to be a device to which you send
{mk_button,...} messages. When the user clicks on the button
a {button_pressed, id} event is sent to the controller.

  Now a button *might* be an image (co-incidentally) - but it might be
pattern of dots on a  programmable braille device (for blind people) -
it's a kind of abstract button if you see what I mean.

  To make it clearer suppose I have a controller and a music player.
here are some message sequence diagrams, to show what happens where.

 GUI  {add_entry,e1}         Controller
  |   {add_button,b1,"play"}       |

 The gui now has an entry and a button
 The user fills in the title of a song in the entry 
 and the presses the button

 GUI                          Controller                Audio controller
  |  {click, b1}                   |                           |
  |------->------------------------|                           |
  |  {read,e1}                     |                           |
  |-------<------------------------|                           |
  |  {e1,data,"song.mpg"}          |                           |
  |------->------------------------|                           |
  |                                |   {play_song,"song.mpg"}  |
  |--------------<-----------------|                           |

  Music plays - the button on the GUI changes to stop

  Now the user clicks the stop button

 GUI                          Controller                Audio controller
          {click, b1}
  |------->------------------------|                           |
  |       {set_entry,e1,""}        |                           |
  |-------<------------------------|    stop_playing           |
  |  {change_button_text,b1,"play"}|------------->-------------|
  |--------------<-----------------|                           |

> gets a {display_image, ...} message, it has to be able to know what the binary
> data means and how to render it.
> >From your description, I figured you are meaning to let the knowledge about
> rendering JPEG images (for example) be a part of the imaging component. This
> means there has to be some generic drawing protocol between image-component and
> gui-component (like for example PostScript/PDF, or in the simplest variant raw
> pixel arrays).
> Is this what you meant?

No (see above)

> I'm asking because I thought I'd try to write such a component, but I need a
> more precise "specification" :-)

Here's the simplest possible spec:

    Controller -> ImageEngine

    [1,N,"BBBBB"]    (Display image)     replies 1 (ok) 2 (no such file)
                     - N    = file name size
		     - BB.. = file name 
    [2,H1,H2,W1,W2]  (set width/height)  replies 1 (ok) 2 (no such file)

    To start the image engine

	> 1234

    The image engine starts and listens to port 1234

    Now If I send the 9 byte message to port 1234
    the image component will display the file "joe.jpg" (if it can find it)


    It replies with the one byte message 1 if it can do this otherwise 2

    Later we can add *bells and whistles* and use UBF for *specifying*
the messaging.


> >   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)
> True
> > > 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.
> It's a "read-only" interface :)
> >>Model-View-Controller pattern
> > How about the TV-Zapper-Controller model?
> Is the TV trying to display video on the zapper?

  No no no.  The zapper only knows how to  make "abstract buttons" and
it  knows when one  of it's  buttons has  been clicked.  Nothing else.
(well a little  more, say buttons, entries, combo-boxes  etc.) but not
*too* much.

  *only* the TV knows how to display the picture.


> /Vlad

More information about the erlang-questions mailing list