From thomas.friedrichsmeier at ruhr-uni-bochum.de  Tue May 31 23:23:36 2011
From: thomas.friedrichsmeier at ruhr-uni-bochum.de (Thomas Friedrichsmeier)
Date: 31 May 2011 23:23:36 +0200
Subject: [Rd] GUI hooks in R [Was: assignInNamespace and new bindings]
In-Reply-To: <42ECBCC7-B920-444A-9BA4-014B994A0C38@r-project.org>
References: <4DE4A82E.7060803@r-enthusiasts.com>
	<201105312211.41716.thomas.friedrichsmeier@ruhr-uni-bochum.de>
	<42ECBCC7-B920-444A-9BA4-014B994A0C38@r-project.org>
Message-ID: <201105312323.40199.thomas.friedrichsmeier@ruhr-uni-bochum.de>

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
1
1
2
2
...
rather than e.g.
1
2
3
1
2
4
3
5
6
...

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.).

> > - graphics::plot.new(): 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.
> > 
> > - grDevices::dev.off(): 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 graphics::plot.new(). 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].

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20110531/8cffa37f/attachment.bin>


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