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

List:       eros-arch
Subject:    [eros-arch] Separation of GUI from logic
From:       Eyal Lotem <gnupeaker () yahoo ! com>
Date:       2003-11-08 2:43:55
[Download RAW message or body]

It seems that EROS is seeking a solid GUI design.
Unfortunatly, it seems that EROS is about to build up
a system that immitates existing GUI designs, which
are quite horrible, in my oppinion.

The components of an EROS Desktop GUI system, as I see
them:

Peripheral Servers/Drivers (Video server, Mouse
server, Audio server):
	Capabilties:
		Low-level access to the peripherals.
	Implements:
		Abstraction of the peripherals, if required for
network transparency or any other feature.

The Window System:
	Capabilities:
		Exclusive capabilities to Peripherals
Servers/Drivers (allowing it to read mouse/keyboard
input and display video)
		Capabilities to send inputs into the user processes
(typically from input widgets)
	Implements:
		Widget Set
		GUI Designer allowing the user to rebuild the
visible GUI's at any given moment
		"Connects" between applications and visible widgets,
peripherals, etc.

The User Object Database (is an application - see
below):
	Capabilities:
		All of the user objects
	Implements:
		Relational database queries according to arbitrary
user object fields
	Inputs:
		Query data
	Outputs:
		Capabilities to user objects

Typical Application:
	Capabilities:
		Input is received via capabilities given by the
Window System. Typically these capabilities will be to
Window System objects (Widgets) but they could also be
the peripherals, perhaps via proxies.
		Capabilities to send output of any type to an
arbitrary receiver (this would be The Window System
for all outputs of a typical application).
	Inputs/Outputs:
		In the spirit of "stdin/stdout", the application
formally specifies its input/output types in a static
definition, which also specifies which entries on its
c-list will be allocated for which input/output types.
		The input/output capabilities in the application
will either be to Window System widgets that
display/read from the user, or to peripherals,
whatever the user explicitly "connected" the
application to.
	Important Note: Applications are not at all aware
what inputs/outputs they are connected to.  Their
inputs/outputs could be to/from the network, a widget,
a file, a command-line or a script.  They have no
concept of "File Dialog", "Window" or "Window
Session".

Note that The User Object Database is also "Just an
Application", except its outputs would typically be
connected to inputs of other applications (Replacing
the "Trusted File Dialog").

The Key Features of this design: 

* Trust: The exclusive control over the visible screen
is in the hands of a single entity (The Window System)
which places that control with the user.  Any
connection of the "Arbitrary Video/Image Data" from
applcations into the Window System is explicitly done
by the user.  This would allow the user to specify
that Arbitrary Video/Image Data is connected to the
full-screen (explicitly approving this), but this will
be visible in the keyboard leds, and is cancelled if
the user is idle for more than a small constant amount
of time (When not connecting to the full screen,
widgets that can contain arbitrary images can be shown
in a special way).  Perhaps a quiet sound (or a cheap
EROS usb lamp :) can also be used periodically or in
the background to remind the user of the untrusted
fullscreen mode.

* Abstraction: Applications need not be aware of their
sources of information and what happens with their
outputs.  This, to me, seems much like the
"stdin,stdout,stderr" protocol in *nix which has been
a great success for simple text processing.  I think
this would allow that same power in today's
applications, except with an unlimited amount of
inputs/outputs.

* Network Efficiency: Unlike X, where the network
boundary is between the peripherals and the toolkit,
this would allow placing the network boundary between
the application and the window system. Most
mouse-movement events, for example, will not result in
network packets. Widgets could feel smooth and local
even for remotely-running applications.

* User customizability:  The GUI will be completely
designable by the user.  All apps could even be used
from the commandline "natively".

* Modular: The design is more modular and allows for
the applications to contain less capabilities to less
meaningful things.  This also lets the application
writers focus on the application separately from its
GUI.

* Diversity: Unbinding toolkits from the applications
allows for far better "theming".  Replacing entire
toolkits is possible without losing any application or
consistency on the desktop.  Replacing the whole look
of the desktop or an application can be done by
downloading "GUI designs" from the web.  GUI designs
could be turing-incomplete specifications of widget
constructions and their connections to applications
inputs/outputs.



__________________________________
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]