• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: John C. Randolph

"John C. Randolph" wrote:
>
> Gentlemen,
>
> I just came across an essay at
>
> http://www.edge.org/3rd_culture/gelernter/gelernter_p1.html
>

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!

Re UIs:
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: http://www.cs.umd.edu/hcil/pad++/

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 window
can move around on its own..

The other good thing is that "alien" windows - eg top level XWindows could
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 
	GUI arena. 
	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
colormap
	entries on an indexed color system. 
	

So there are a lot of things I think are more fundamental to get right before
we design our own gui system..

Rob

[ Next ]
• [ Previous ] In reply to: John C. Randolph