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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
