grob questions

Hi


Gabor Grothendieck wrote:

On 10/4/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:

Hi


Gabor Grothendieck wrote:

If I run the following example from:
http://www.stat.auckland.ac.nz/~paul/grid/doc/grobs.pdf

grid.newpage()
pushViewport(viewport(w = 0.5, h = 0.5))
myplot <- gTree(name = "myplot", children = gList(rectGrob(name = "box",

+ gp = gpar(col = "grey")), xaxisGrob(name = "xaxis")))

grid.draw(myplot)
grid.edit("myplot::xaxis", at = 1:10/11)
grid.edit("myplot::xaxis::labels", label = round(1:10/11, 2))
grid.edit("myplot::xaxis::labels", y = unit(-1, "lines"))

then

str(myplot$children$xaxis)

lists 'at' but not the 'labels'.

yet if I do this then the labels are listed:

xx <- xaxisGrob(name = "myX", at = 1:10)
childNames(xx)

[1] "major"  "ticks"  "labels"


1. How do I get to labels in the first case?

First, if the xaxisGrob has at=NULL then it calculates its tick-marks at
drawing time (based on the viewport it gets drawn in).  So it does not
store any labels (it doesn't know what they are until it gets drawn). If
you specify a non-NULL 'at' then the axis creates labels.

Second, grid grobs are standard R objects (copy-on-modify) so the object
'myplot' is not the same object that is being modified by the calls to
grid.edit().  grid.edit() destructively modifies a copy of the grob that
grid has stored on its display list;  you refer to the appropriate grob
via its name (not via an R object).  By comparison, editGrob() takes a
grob and returns a modified copy of the grob, for example ...

Just one clarification.  What is the scope of names?
In a recent post

  https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078653.html
  https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078656.html

it seems that one had to use absolute paths and that seems to be the
case here too where as mkondrin pointed out earlier in this thread

  https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078635.html

that get.grid("myplot::xaxis::labels")$label works.

Its not clear to me whether names:

- must be in absolute paths
- can be relative to some position under some conditions
- are global across all grob names in use and can be referred to directly
as long as they are unique among all grobs defined so far.

It seems absolute path names work but I am not sure whether the
other possibilities can work under some conditions too.

Also what the scope of viewports?   Absolute path? Relative path?
Global names?  Does it work the same way?  I think at least
absolute and relative paths are avalable here but could you confirm
my understanding and whether the situation is the same for
viewports and grobs?

(In the Windows, and analogously in UNIX, file system one can write
\usr\myname or position oneself to \usr using cd and then refer to
myname in a relative way:

cd \usr
dir myname
)

The distinction is not between "relative" or "absolute" paths, but
between "strict" and "not strict" paths.

Matching a path always *starts* from your current "position" (so in that
sense it is always "relative" and never "absolute").  When working with
viewports, there is a current viewport tree and it is possible to be in
different positions within that tree --- via [push|down|up]Viewport()
--- so a path may have different meanings depending on where you are.
(The seekViewport() function is sort of absolute because it always
starts from the root of the viewport tree, but a non-strict
seekViewport() [see below] behaves quite differently from an absolute
filesystem directory path.)  When working with grobs, you tend to always
be at the "top" or "root".  You are either: working off-screen with a
single specific grob (gTree) so you are always at the top of that gTree;
 or working with the grid display list, in which case you have a list
of grobs and gTrees, which are searched one after the other.

The functions that take paths for grobs, such as grid.edit(), and for
viewports, such as downViewport(), have an argument 'strict' which
controls whether the path should be matched from the current position or
whether the search can start from the current position and we'll match
the path if it occurs anywhere below the current position.  (There are
also 'grep' and 'global' arguments so you can get multiple matches where
it makes sense.)

In some cases, grid has to make use of a path on its own, without
knowing explicitly whether the path is strict (e.g., when you specify a
path in a 'vp' slot).  In those cases, grid interprets the path as
strict (so that, for example, grid has some chance of undoing the
navigation down to a viewport).

Regarding uniqueness of names, all viewports *which share the same
parent viewport* must have unique names (same for grobs).  You can,
however, have several grobs with the same name on the display list.
i.e., the following produces two separate grobs on the display list

grid.rect(name="rect")
grid.rect(name="rect")

Does that make things any clearer?