[elysium-developers] Fw: Graphics architecture?

[Claus M. <cla...@ma...>]

> As our project progresses, the need for a more advanced interaction
> mechanism than a single-line command interpreter with only predefined
> commands and no backspace becomes obvious. As implementing a normal
> WIMP-style window manager on top of Elysium would be somewhat
unimaginative,
> Kasper Lund, Jakob Andersen and myself have been discussing
user-interaction
> techniques for some time. Especially the work by Michel Beaudouin-Lafon
has
> inspired our discussions, and since Kasper on a daily basis actually works
> on implementing a CPN-editor based on Michels work we have had an
excellent
> chance to watch a post-WIMP system in action.
>
> WIMP stands for "Windows, Icons, Menus and Pointing" and is a result of
the
> Xerox Star system from the early eighties. WIMP is the system we associate
> with a graphical interface today - System X, X/Motif and Windows are all
> WIMP-style graphical interfaces. The main problem with such interfaces are
> that the complex tasks they are able to perform result in quite large
> amounts of screen real estate are occupied by Icons, task bars and
suchlike.
> What we want is a system that uses Direct Manipulation more efficiently
than
> today's interfaces, meaning that whenever we want to interact with an
> object - a sheet of paper, for instance - the interaction does to a lesser
> extend rely on icons, menus and dialogue boxes and more on actually
> manipulating the document itself. When you want to change the font on a
> subset of the text for example, this should be done by manipulating the
text
> directly instead of pressing an "italics" button. Various techniques have
> been evolved to facilitate this, and some are used today in special
> applications such as "Maya" but they lack a full-scale window-manager
> implementation.
>
> To implement such a system using a traditional 2d-graphics library is
> tedious and it seems that it would be very efficient to implement it in
> OpenGL. OpenGL has many great adventages, none of which is being easy to
> implement, and thus it would be a great help if we could adapt an already
> existing driver model to our needs. It seems that the new DRI driver model
> used in the upcoming xfree 4.0 (development release 3.9.18 is the latest
> alpha) might suit these needs. Kasper has promised to look into what it
> would take to make a DRI loader and if it seems that it is possible to use
> the format, I would very much like some help in implementing such a
loader.
> Not because it is a great task (hopefully it isn't), but because I really
> need it for further development of the user interface so I have something
to
> post for public comment.
>
> As always, I am looking forward to your comments
>
> - xmentor
>