From murdoch at stats.uwo.ca  Sat Nov  6 02:00:15 2004
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Sat Nov  6 02:00:22 2004
Subject: [Rd] idea (PR#7345)
In-Reply-To: <2E19048A-2F76-11D9-A082-000D93C24D64@stat.harvard.edu>
References: <20041105121805.3989110FA2@slim.kubism.ku.dk>
	<418B7AC7.8000103@statistik.uni-dortmund.de>
	<2E19048A-2F76-11D9-A082-000D93C24D64@stat.harvard.edu>
Message-ID: <md8oo0dmfd6hlnr3a89jd2osagevs192ln@4ax.com>

On Fri, 5 Nov 2004 14:01:01 -0800, Byron Ellis
<ellis@stat.harvard.edu> wrote:

>The most obvious, and by far most difficult route, would be to make 
>graphics devices first class citizens (IIRC Duncan TL has brought this 
>up elsewhere) wherein you would aDev <- edit(aDev). That brings things 
>to the device level (what you want) and a static device could act 
>accordingly (i.e. not invoke a redraw). Obviously the most difficult as 
>it would be a massive upheaval of base graphics (I suppose all of this 
>could all be grouped under a category of "event-based streams," 
>graphics events, XML SAX events, file events--aka connections, etc. 
>Doesn't CL or Scheme have something along those lines?). But, as 
>mentioned in the thread, pretty speculative but you never can tell what 
>someone might hunker down and implement :-)

Take a look at grid.  I think it's more likely something like this
would be built on top of grid than on top of base graphics.

Or, if you want to try it:

Take a look at grid.  I think you'll find it a lot easier starting
there than starting with base graphics.

Duncan Murdoch


[Rd] idea (PR#7345)
Duncan Murdoch