Re: [Rd] GUI hooks in R [Was: assignInNamespace and new bindings]

From: Thomas Friedrichsmeier <>
Date: Tue, 31 May 2011 23:23:36 +0200

On Tuesday 31 May 2011, Simon Urbanek wrote:
> The history entries are somewhat in a grey area, because most GUIs use
> their own implementation of history (and thus they are irrelevant) and the
> *history() commands are documented to only use readline-backend. That
> said, they could be easily used by all GUIs if the Windows code is
> amended.

Actually, I would suggest to use a different solution, though: This is not really a problem that needs to be addressed on a low level of pointers to C functions. Perhaps it would make more sense to allow to set some R function(s) to handle these via options() (or perhaps via a dedicated gui.options()).

> > - utils::select.list() and utils::menu(): I want to show my own UI if
> > graphics==TRUE. Currently, select.list() has special code for windows,
> > "aqua" and tcltk; menu() essentially assumes the same code. Give me a
> > way to run register my own UI.
> ptr_do_selectlist provides the customization and could be extended to other
> platforms.

See above. But yes, if at least it was cross-platform, that would be nice.

> > - base::system(), base::system2(): As you will be aware, capturing the
> > output of system commands in a GUI is tricky on Unix. I do have a
> > solution for that, but I need to run synchronization code at the start
> > and end of system() and system2(), in order to get interleaving right.
> > Give me a hook, each, at the start and end of these functions.
> I'm not sure I understand your concern here. What exactly is your worry?
> Capturing output is trivial since it simply involves creating a pipe when
> you initialize R which you can read while R is running and the
> synchronization is provided by the OS, no magic involved.

Is that pipe buffered? In my setup it is. And so consider code like this:

   for (i in 1:10) {

       print (i)
       system (paste ("echo", i)) 

How do you ensure that this results in
rather than e.g.

I could not get it to work for RKWard without adding code to make sure the "other" output is flushed. (Note: I'm capturing regular R output via R_WriteConsoleEx, since I am interested in the differentiation between output types that this provides. So I cannot simply push that down the same pipe.).

> > - I need a hook *before* the new plot is started,
> > in order to properly implement device-independent plot history. I would
> > appreciate not having to implement my own graphics device just to be
> > able to run some code at this point.
> >
> > - I need a hook before the device is closed. Also
> > for plot history.
> >
> > - grDevices::dev.set(): I need a hook after the new device has been set.
> > Also for plot history.
> >
> > - grid::newpage(): See Of course, even better, I
> > would like to have a hook that is called every time before a new page /
> > frame is started on a device.
> For all of the above: all of them are already available a device callbacks
> (newPage, close, activate and newPage again).

Quoting myself: I would appreciate not having to implement my own graphics device just to be able to run some code at [these] point[s].

Thomas mailing list
Received on Tue 31 May 2011 - 21:25:55 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 01 Jun 2011 - 16:20:15 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive