Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Mar 1999 01:41:37 -0500 (EST)
From:      eagle@phc.igs.net
To:        tlambert@primenet.com
Cc:        asmodai@wxs.nl, brian@CSUA.Berkeley.EDU, freebsd-chat@FreeBSD.ORG
Subject:   Re: A BSD-licensed GUI toolkit?
Message-ID:  <199903070641.BAA02704@eagle.phc.igs.net>
In-Reply-To: <199903061812.LAA03755@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert was seen writing:

> I actually believe that the future lies with things like "VNC":
> 
> 	http://www.uk.research.att.com/vnc/
> 
> 
> Because VNC can replicate frame buffer contents over a network
> (a simplified description, to be sure), you can get rid of most
> of the overhead of X11 by declaring that your network transport
> is a replication mechanism of some kind.
> 
> This basically means that there are three pieces to be built:
> 
> 1)	A distributed, coherent virtual framebuffer piece with
> 	an Alpha channel
> 
> 	This is the tricky part.  This basically allows applications
> 	on multiple machines to write to the same frame buffer, and
> 	to introduce clipping based on a police enforced by a
> 	management piece (traditionally, a window manager) for each
> 	virtual connection to the framebuffer.
> 
> 	Clearly, backing store is the responsibility of the client.
> 
> 2)	A replication piece
> 
> 	Ideally, you would replicate by taking a virtual framebuffer,
> 	making it a Corba object, and embedding it in a real
> 	framebuffer.
> 
> 3)	A direct-to-framebuffer graphics library interface
> 
> 	This should probably resemble the Win32 API, in order to
> 	make applications easy to port.  You could probably
> 	leveage the commercial backing of the WINE API library
> 	code (WINE itself continues to languish).
> 
> 4)	A real framebuffer object, preferrably capable of having
> 	a CORBA frambuffer object embedded in it.
> 
> 	This *must* be very thin.  Target it for no more than
> 	512k.  Expect to implement it on VESA on DOS (or DR-DOS),
> 	and expect to implement it on a single FreeBSD boot floppy
> 	or a FLASH RAM card.  It must include transport interfaces.
> 
I fail to see how this solves the issue at hand, with x library's as
this kind of implementation would have to replace x, destroying the
compatibility with existing software in the proccess. While vnc's frame
buffer replication ideas are indeed interesting, it goes nowhere to
solving the problem that we do have.

that is quite simply a stable usefull x toolkit, I do agree that mofif
is dead, and that work on it would be aproaching useless though.

So that leaves us with the prospect of designing and implementing a new
gui toolkit. 


Rob



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903070641.BAA02704>