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

Simon Urbanek simon.urbanek at r-project.org
Tue May 31 22:56:08 CEST 2011


On May 31, 2011, at 4:11 PM, Thomas Friedrichsmeier wrote:

> On Tuesday 31 May 2011, Simon Urbanek wrote:
>> I would expect so, but I'll let Luke comment on it. It is definitely a very
>> bad idea.
>> 
>> R provides facilities for customization and other GUIs are using them
>> properly. If you are lacking anything, I would suggest asking here first -
>> it is much easier to add a useful customization path to R than to deal
>> with hacks that are fragile due to unjustified assumptions.
> 
> I am not entirely convinced that this assessment of the relative difficulty of 
> these options is also true for developers outside the R core group.
> 
> But, here's my list of requirements. I know that some of these have been 
> requested on r-devel before. I'd appreciate, if you can help me with at least 
> some:
> 
> - utils::loadhistory(), utils::savehistory(), utils::timestamp(): I am not 
> using, and can not use readline history. prt_R_loadHistory, ptr_R_savehistory, 
> and ptr_R_addhistory are not available on Windows. And they could do with a 
> bit more documentation, if GUIs are expected to use these. I need a way to 
> interface with my GUIs history mechanism, cross-platform.
> 

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.


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


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


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

Cheers,
Simon




>> As a user, I'm
>> really worried about packages modifying other packages behind my back (but
>> I may be more paranoid than others).
> 
> On the level of plain R code: I am very certain that the customizations that I 
> am doing are perfectly harmless, because it's pretty trivial stuff. You don't 
> have to trust me on that. And of course not any more than you trust the rest 
> of any other person's work, in the first place.
> 
> Of course, if what I am doing is "illegal" because it steps on the compiler's 
> turf, then my assumptions do not hold, indeed. That's what I'm worried about.
> 
> Regards
> Thomas
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list