The wrapper project

[Vlad Dumitrescu]

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. Only the GUI has the
physical ability to actually show something on a screen (or similar). If the GUI
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?

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

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

/Vlad