From p.murrell at auckland.ac.nz  Wed Jun  8 22:15:31 2005
From: p.murrell at auckland.ac.nz (Paul Murrell)
Date: Wed Jun  8 22:15:42 2005
Subject: [Rd] Re: [R] Problem going back to a viewport with gridBase
References: <971536df05053020191ebe8f44@mail.gmail.com>	
	<971536df050602140356cc80b4@mail.gmail.com>	
	<429FB4AE.5030105@stat.auckland.ac.nz>	
	<971536df0506030554396c2374@mail.gmail.com>	
	<42A4D286.5090208@stat.auckland.ac.nz>	
	<971536df0506061924438870f0@mail.gmail.com>	
	<42A612FF.5020408@stat.auckland.ac.nz>	
	<971536df05060718376e609133@mail.gmail.com>	
	<971536df0506071857730811a1@mail.gmail.com>	
	<42A6621D.9020101@stat.auckland.ac.nz>
	<971536df0506072044583f7dc1@mail.gmail.com>
Message-ID: <42A751E3.2080500@stat.auckland.ac.nz>

Hi


Gabor Grothendieck wrote:
> Thanks.  Yet one other comment to consider when thinking
> about this.  Even if its not possible
> or advisable to guarantee order, even without the hash=
> idea, it may be possible to guarantee that default names
> are generated in some order that can be used by
> getChildren to ensure that it returns the children in
> the same order they are created or perhaps even some sort
> of timestamp can be attached to objects to facilitate 
> later traversal.


Thanks Gabor.  I will look at a way to ensure that childNames(vpTree) 
returns the names in the order that they were pushed.  This may be as 
simple as porting the mechanism used for grobs and gTrees, where 
(drawing) order is very important.

Paul


> On 6/7/05, Paul Murrell <p.murrell@auckland.ac.nz> wrote:
> 
>>Hi
>>
>>
>>Gabor Grothendieck wrote:
>>
>>>Here is the code once again.  This time I have supplied two
>>>names methods and a getChildren.viewport function to
>>>encapsulate the corresponding grid internals.  It would
>>>be easiest if grid provided these itself but in the absence
>>>of that this does encapsulate dependencies on grid
>>>internals to a well defined set of functions.   Note that
>>>names is only used in 'with' and 'with' will be eliminated
>>>once Deepayan adds the use.viewport= (or whatever
>>>its called) to print.   I am not sure from your response
>>>whether or not you intend to add these items to the grid
>>>API but in any case this provides an intermediate
>>>level of safety.
>>
>>
>>Yep, I've made a note to look at adding these to the grid API.
>>Thanks.
>>
>>Paul
>>
>>
>>
>>>library(grid)
>>>library(lattice)
>>>
>>>pushLayout <- function(nr, nc, name="layout") {
>>>  pushViewport(viewport(layout=grid.layout(nr, nc), name=name))
>>>  for (i in 1:nr) {
>>>    for (j in 1:nc) {
>>>      pushViewport(viewport(layout.pos.row=i, layout.pos.col=j))
>>>      upViewport()
>>>    }
>>>  }
>>>  upViewport()
>>>}
>>>
>>>names.vpPath <- names.viewport <- function(x) x$name
>>>
>>>with.vpPath <- with.viewport <- function(data, expr, ...) {
>>>      # if data is a vpPath it cannot be ROOT since
>>>      # NULL will never dispatch here
>>>      depth <- if (data$name == "ROOT") 0 else downViewport(names(data))
>>>      result <- eval.parent(substitute(expr))
>>>      upViewport(depth)
>>>      invisible(result)
>>>}
>>>
>>>getChildren.viewport <- function(x) x$children
>>>
>>>grid.newpage()
>>>
>>># specify number of cells to fill and number of rows
>>>n <- 5; nr <- 3
>>>
>>>nc <- ceiling(n/nr)
>>>downViewport(pushLayout(nr, nc))
>>>
>>>vpt <- current.vpTree(all = FALSE)
>>>for(k in 1:n) with(getChildren.viewport(vpt)[[k]],
>>>      print( xyplot(v ~ v, list(v = 1:k)), newpage = FALSE )
>>>)
>>
>>
>>--
>>Dr Paul Murrell
>>Department of Statistics
>>The University of Auckland
>>Private Bag 92019
>>Auckland
>>New Zealand
>>64 9 3737599 x85392
>>paul@stat.auckland.ac.nz
>>http://www.stat.auckland.ac.nz/~paul/
>>
> 
>>


-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/


[Rd] Re: [R] Problem going back to a viewport with gridBase
Paul Murrell