Re: [R] grob questions

From: Paul Murrell <p.murrell_at_auckland.ac.nz>
Date: Wed 05 Oct 2005 - 06:50:16 EST

Hi

Gabor Grothendieck wrote:
> On 10/4/05, Paul Murrell <p.murrell@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?

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/

______________________________________________
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Received on Wed Oct 05 07:16:40 2005

This archive was generated by hypermail 2.1.8 : Fri 03 Mar 2006 - 03:40:35 EST