The wrapper project

[Joe Armstrong]

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"}  |
     {change_button_text,b1,"stop"}|------------->-------------|
  |--------------<-----------------|                           |


  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

	> start_engine.sh 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)

	  [1,7,$j,$o,$e,$.,$j,$p,$g]  

    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.

/Joe



> /Vlad
>