[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