[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    [eros-arch] Tight coupling
From:       Eyal Lotem <gnupeaker () YAHOO ! COM>
Date:       2003-11-04 23:07:06
[Download RAW message or body]

Note: Explaining my ideas in this message was quite
difficult and I may have not been totally clear or
sometimes redundant, please bear with me here :)


All the suggested GUI designs for EROS seem to me as
making one fatal mistake:  Tight coupling between the
"physical" GUI layout and the application logic and
capability model.

I think another level of indirection between what the
user eventually sees and the application logic must
exist.

	Firstly, this would allow the user to customize his
GUI without any arbitrary limitation (For example,
dragging a "movie player" display/widget from anywhere
into his "Favorites" should be possible, regardless of
the movie player program logic).
	Secondly, hard-coding program logic according to
arbitrary GUI decisions and vice versa is better
avoided.


To try and convey my idea of how an application should
look like, I'll examine an example Movie Player
application.

A Movie Player would for example define a set of
inputs/events:

Encoded Data Stream
Sound Sync Events
Clock Tick Events
User Play/Stop/Pause/Resume Events.

And a set of outputs:

Video Stream
Audio Stream
Mixer Settings

The movie player logic itself would include a handler
for each of the inputs/events that generates the
outputs in some very abstract/generic way that is just
low-level enough to be "fast" (For example, the video
could be generated into a given buffer, where the
underlying system decides if this buffer is eventually
sent over a socket or is an LFB directly to the
backbuffer of the screen).

Linking between "Play/Stop/Pause/Resume Events" and
buttons with icons or command line invocations is out
of the scope of the movie player.

The movie player process will have capabilities only
to its outputs, whereas its inputs will be sent to it
from another entity (Probably the GUI system).  The
movie player process does NOT know if its audio/video
streams are put into files selected via Save As, into
sockets or thrown away.  The movie player does not
have capabilities to the file selection dialog, or to
draw things directly.

Instead, the movie player provides logic which is
useless without a trusted component in the GUI system,
which is the "GUI designer" that links the inputs to
files, static buffer objects, or whatever it wishes. 
Also linking the outputs to appropriate display
widgets, other files, or anything else.

Applications do not ever handle windows, dialogs,
widgets or user-events directly.  This allows putting
less trust in applications and I think it follows
EROS's general direction of process modularity.

It could also be more secure because most programs
would not need or be able to output arbitrary images
confusing the user.  All arbitrary images that are
displayed from programs could be surrounded by a frame
that necessarily doesn't surround any other display
widgets, making it trivial to distinguish "fake"
widgets from authentic GUI ones.  Things that require
authenticity like file selection dialogs (closer to
relational databases searches in my mind :) could be
special widget types (they are part of the GUI system
and are drawn differently).

P.S: The example of a sub-session of desktop within
desktop is often brought up.  Why is this useful?  Why
can't the sub-session objects/windows run on top of
the parent session?

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]