Tk, with some discussion that may be relevant for other packages. The implementation is available as a source package and and as a Windows binary package. (The Windows library may not be built quite right.)
Just for fun, a
tkpersp is available.
This is intended only as a prototyping device, an existence proof of sorts. No guarantees of stability...
Tkentity the R graphic should be. There are two choices: a widget or an image. Adding a new image type seems to require less programming, so I have taken that route.
Next is the question of how to get R graphics output into the image. Some choices:
X11---I don't believe there are analogous concepts on Windows or MacOS (please let me know if there are).
TkC level drawing operations. This is feasible, but the main limitation is that
Tkdoes not support font rotation, so that part would have to be added in some way. The BLT widget set does support text rotation at the
Tcland C levels but is only available for
X11and Windows, not MacOS i believe.
With this approach it probably makes sense for the device opening
function to create the
Tk image with the specified name. The
closing function deletes the image. If the image is deleted in
then the device should be closed.
X11if the current
devX11.ccode were factored out a bit into the pure drawing part and the window/event management part---the pure drawing part could then be re-used. I'm not sure how hard it would be with the Windows or MacOS versions.
Windows already provides a metafile device that can be used to draw to the clipboard. The only wrinkle, other than trashing the clipboard, is that the way things are set up the device has to be closed to get the metafile. This is the way Windows metafiles work, and I think MacOS picture objects do too. To keep the device open would require closing the graphics context, opening a new one, and seeding it with the metafile. This is possible but would require modifying the windows driver. Since what we have is workable, for now I decided to go without driver modification and live with the idea that the device is closed by extracting its image.
JPEG devices are already using pixmaps
to hold their output and using
XGetImage to access the pixmap
contents. A small modification, which I have added to the R sources,
X11 driver to be set up as type
XImage with a call
X11("XImage", ...)The driver just draws to the pixmap; no files are created. A function
R_GetX11Imagedeclaration>= Rboolean R_GetX11Image(int d, XImage **pximage, int *pwidth, int *pheight)
R_GetX11Image(links are to index).
is used to get an image of the current pixmap. This function can also
be used with
PNG devices; it does not close the device.
Performance of this approach on X11 seems adequate; on windows it is
OK for the simple example but not very good for
tkpersp, at least
on my system. But it should do for prototyping purposes, which is all
it is intended for.
On the Windows version for some reason when run with
Rgui the R
window comes to the front each time you create a Tk image, probably
something with the device being closed.
tkrplotpackage. It consists of the functions
<higher level functions>= tkrplot(parent, fun) tkrreplot(lab, fun = lab$fun) tkpersp(...)
tkrplot creates and returns a
Tk label widget
Tk image of type
Rplot. For now the size is
hard-wired. The plot is created by calling
fun with a special
device used create the image.
fun to place a new plot in the
tkpersp is called like
persp but produces a plot in which some
of the parameters of
persp are controlled graphically.
Tkside implements a new image type,
Rplot. Creating an image of this type with
image create Rplot ?name?extracts the image for the current device as a metafile, via the clipboard, or as an
XImageand closes the device. The device must be of the appropriate type---a clipboard metafile device on Windows or an