playwith(expr,
new = FALSE,
title = NULL,
time.mode = FALSE,
labels = NULL,
data.points = NULL,
is.lattice = NA,
viewport = NULL,
top.tools = playApplicationTools,
left.tools = playInteractionTools,
bottom.tools = list(),
right.tools = list(),
...,
show.call = TRUE,
win.size = c(640, 500),
modal = FALSE,
on.close = NULL,
eval.args = NA,
invert.match = FALSE,
envir = parent.frame(),
playState = if (!new) playDevCur(),
plot.call)
plot(mydata)
.
Note, this can have lots of arguments, just like a normal plot call (see examples).
Can also be a chunk of code in {
braces}
, but that form does not allow inTRUE
open in a new window, otherwise replace the current window (if one exists).identify
.
If missing, it will be guessed from the plot call arguments.NA
, the call name is matched against known Lattice function names.gtkToolItem<
playState
object.
These can then be accessed by user-defined tools. The default tools will recognise the following
extra arguments:
[object Object],[object ObjectFALSE
to hide the plot call text-box ("address bar") and associated buttons.TRUE
, the session will freeze until the window is closed.playState
object
will passed to the function. If the function returns TRUE
, the window will not be closed.TRUE
, FALSE
, NA
(don't eval global vars)
or a regular expression matching symbols to evaluate. See below.eval.args
.environment
to use in evaluating the call arguments (see eval.args
)playState
object for an existing plot window.
If given, the new plot will appear in that window, replacing the old plot.
This over-rides the new
argument.call
object), if given this is used instead of expr
.playwith
invisibly returns the value from the plot call.cairoDevice
package) and several toolbars.
There is a call toolbar (similar to the "address bar" of a web browser) at the top,
showing the current plot call, which can also be edited in-place.
Then there are up to four toolbars, one on each side of the plot.
The tools to be placed in these four toolbars can be specified
if necessary.
With the autoplay
facility, playwith
can function
as a default graphics device (although it is not technically a
graphics device itself, it is a wrapper around one).
The pre-defined tools can be listed with names(toolConstructors)
.
See playTools for a description of the pre-defined tools,
and playwith.API for help on defining new tools.
Note that different sets of tools will be used by default for calls to
splom
, cloud
and wireframe
.
Three types of plots are handled slightly differently:
is.lattice=TRUE
.is.lattice=FALSE
).viewport
argument to enable interaction. This has not been well tested.playwith
makes a lot of guesses
about the plot, the data, and how to interact with them.
Some interaction is based on evaluating and changing arguments to the plot call.
This is designed to work in common cases, but could never work for all
plots. For basic interaction, ensure that the call accepts xlim
and ylim
arguments.
Generally, it can be expected to work best with Lattice plots.
The locations and type of data points will be guessed from the plot call.
An attempt will also be made to construct labels to identify the data points.
These guesses may be wrong in complex cases, in which case
you can pass the correct values in as data.points
and/or labels
.
Please also contact the maintainer to help improve the guesses.
In order to interact with a plot, its supporting data needs to be stored:
i.e. all variables appearing in the plot call must remain accessible.
By default, all non-global data is copied into an attached environment and stored.
The default setting eval.args=NA
causes variables appearing in the
plot call to be evaluated and stored, except if they are defined in the
global environment (i.e. user workspace). This method should work in most
cases, but: Functions appearing in the plot call will be evaluated each
time the plot is updated -- so random data as in plot(rnorm(100))
will keep changing, with confusing consequences! You should therefore
generate random data prior to the plot call. Changes to variables in the
global environment will also cause inconsistencies in previously generated
plots (e.g. labels on data points may be wrong).
If eval.args=TRUE
then variables appearing in the plot call will be
evaluated and stored even if they are defined in the global environment.
Use this if the global variables might change (or be removed) before the
plot is destroyed.
If a regular expression is given for eval.args
then only variables
whose names match it will be evaluated, and this includes global variables,
as with eval.args=TRUE
. In this case you can set invert.match=TRUE
to evaluate variables that are not matched.
For example eval.args="^tmp"
will evaluate variables whose names
begin with "tmp"; eval.args="^foo$", invert.match=TRUE
will evaluate
everything except foo
.
If eval.args=FALSE
then the plot call will be left alone
(not evaluated until plot time).autoplay
, playTools, playwith.APIif (interactive()) {
treering2 <- window(treering, start=1)
playwith(plot(treering2, xlim=c(0,300)),
time.mode = TRUE,
labels = paste(time(treering2), "CE"))
library(lattice)
playwith(xyplot(Income ~ log(Population / Area) | state.region,
data = data.frame(state.x77)),
label.style = gpar(col="red", fontfamily="HersheySans",
cex=0.7))
xx <- rnorm(50)
playwith(plot(density(xx, bw = cur.time)),
time.vector = seq(0.1, 1, by=0.05))
}
Run the code above in your browser using DataLab