On 6/6/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> Gabor Grothendieck wrote:
> > On 6/2/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> >
> >>Hi
> >
> >
> > Thanks. I have mucked around in vpTree structures and discovered its
> > actually quite easy to specify children so I have changed my example
> > so that instead of naming the children of 'layout' and then remembering
> > coordinates linked to the names of the children of 'layout' in
> > the 'coords' structure (which really just duplicates state information
> > already available in grid) it simply follows the order
> > of the children of 'layout' directly. This permits elimination of 'coords'
> > and the two naming functions. Using the depth approach you advocate,
> > 'with' also becomes shorter and I think I have it to the point where it
> > works
> > with both vpPath and viewport classes. Once Deepayan implements
> > the use.viewport= argument to print, 'with' can be eliminated too. No
> > questions this time but I thought I would post the latest version for
> > completeness. Regards.
>
>
> Ok. I can see this working ... for now. The disadvantage with this
> approach is that it makes use of the undocumented, internal structure of
> a viewport tree to grab a list of child viewports. A worse example of
> the same thing is that the with() methods make use of a happy
> coincidence that both viewport objects and viewport path objects share a
> component called "name" (and an even happier coincidence that they
> contain the same information). I think it would be cleaner and better
> practice, despite requiring longer code, to make use of the documented
> interface which requires specifying viewport names and viewport paths.
> The internal structure of objects is not guaranteed to be stable.
Perhaps accessor functions could be provided that allow one to
retrieve the name of a viewport and the name of a vpPath in
a safe way. These could be as simple as:
names.viewport <- names.vpPath <- function(x) x$name
Similarly an accessor function to safely retrieve the children would
be nice. Again, it should ideally be possible to
have a generic with methods for various grid classes.
Then the relevant line in the code concerning name
could be written in a safe way like this:
depth <- if (data$name == "ROOT") 0 else downViewport(names(data))
and similarly for the children.
>
> Paul
>
>
> > [pushLayout is same as before except there are no names on the
> > children of 'layout' and the rest is new]
> >
> > 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()
> > }
> >
> > 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(data$name)
> > result <- eval.parent(substitute(expr))
> > upViewport(depth)
> > invisible(result)
> > }
> >
> > 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(vpt$children[[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
> [EMAIL PROTECTED]
> http://www.stat.auckland.ac.nz/~paul/
>
>
______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
