Namespaces, UI, etc.
Sat, 08 Jul 2000 21:35:46 +0100
"John C. Randolph" wrote:
> I just came across an essay at
Yes, that does say a lot about the kind of stuff I want to do.
I did read this before, but I lost the URL!
In the short term I think porting XFree86 is the best option.
Even this would seem to me to be a long way off!
In the long term, I think a new GUI would be a good idea,
as long as we can make another program which will accept X
requests and render them to the new system in an efficient
manner. It may be possible to do this in a fairly modular
way with XFree86 4.0
One interesting UI paradigm that I saw was "zoomable" UIs:
It seems a lot more sensible and intuitive to me than overlapping
window based systems, which are becoming kind of unmanageable.
Also I *think* it closes off the expose event covert channel, as no
can move around on its own..
The other good thing is that "alien" windows - eg top level XWindows
fit in relatively easily.
The main points I'd like for an eros gui:
* Pixel independant -
This does not mean scaling is always done in the display server.
That would be have a terrible impact on performance of games, etc.
It means that an integral part of the drawing interface is the
server telling the client a scale factor. This can be ignored
if it is not practical to scale.
* Rich but concise imaging model -
Need to look at Postscript, libart, quartz, berlin etc.
* Network aware -
I'd like to see this based on whatever method we decide on for
making key invocations over networks, and the full interface
to be described via whatever IDL mechanism we make up.
* Full security -
Must be no covert channels - eg unrestricted cut & paste,
server locks, some expose events etc etc.
* Relocatable client parts-
Like NeWS. As the capability basis of eros makes it possible to
safely run untrusted code in a mutually suspiciuos environment,
this could provide a massive speed boost for remote programs.
It may even be possible to do progressive relocation,
attempting to minimise network traffic and maximise CPU utilisation.
This could of course be very useful for other things outside the
I envision a protocol in which the programs communicate what kind
of architecture they are running on, and relocate in binary form
if possible. (This would normally only be very CPU intensive bits
anyway.) Other bits could be relocated in things like Postscript
or Java bytecode.
Of course this is all very speculative, and there are a lot of
resource restriction issues - eg useing up too much memory or CPU,
(these may be covered by space banks and CPU reserves?) but also things
like requesting hundreds of fonts to be loaded or getting too many
entries on an indexed color system.
So there are a lot of things I think are more fundamental to get right
we design our own gui system..