[R-SIG-Mac] bypassing the R.app help browser?
John Fox
jfox at mcmaster.ca
Thu Aug 21 16:12:15 CEST 2014
Dear Brian, Peter, and Simon,
As I explained, I removed the call to tkwait.window() in Rcmdr modal
dialogs, and I've now had a chance to test the consequences. AFAICS, in
almost all cases, the change is benign. Because control is returned to the R
command prompt before a dialog closes, there is the possibility that a user
will put R in a state that produce an error (e.g., erasing a data set that
existed when the dialog opened), but that seems to me unlikely.
In some cases, however, when the OK button is pressed in a dialog, another
dialog opens, and, to work properly, the function dispatched by the OK
button should wait until the second dialog closes, since it requires
information supplied by the user in the second dialog. Removing
tkwait.window() from the second dialog produces an error in this
circumstance. I've therefore introduced an optional force.tkwait argument,
which defaults to FALSE, to the Rcmdr dialogSuffix() macro; setting the
argument to TRUE in a secondary dialog solves the problem that I outlined.
With these changes, I think that the Rcmdr now behaves correctly on all
platforms, permitting, e.g., help pages to display properly under Mac OS X
and in RStudio.
Thanks to everyone who addressed this problem,
John
> -----Original Message-----
> From: r-sig-mac-bounces at r-project.org [mailto:r-sig-mac-bounces at r-
> project.org] On Behalf Of John Fox
> Sent: Wednesday, August 13, 2014 12:57 PM
> To: 'Prof Brian Ripley'; 'peter dalgaard'
> Cc: 'R-SIG-Mac'
> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
>
> Dear Brian and Peter,
>
> Thanks for picking up this issue.
>
> The behaviour that Brian reports is exactly what I observed, and the
> Tcl/Tk
> doc that he quotes is what I consulted. It's not surprising to me that
> the R
> process waits until the Tk window calling tkwait.window() is destroyed.
> I
> suppose that because the internal help browser runs under the R
> process, it
> too waits, while an external browser -- as is spawned by help.start() -
> -
> runs in an independent process.
>
> As I mentioned, I've removed the call to tkwait.window() in the Rcmdr
> sources (it's in a "macro" called by every Rcmdr modal dialog) and will
> test
> whether there are negative consequences. I've observed none so far.
>
> BTW, the same issue arises when the Rcmdr is run inside of RStudio,
> which
> directs help to its own browser.
>
> Best,
> John
>
> > -----Original Message-----
> > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk]
> > Sent: Wednesday, August 13, 2014 11:08 AM
> > To: peter dalgaard; John Fox
> > Cc: R-SIG-Mac
> > Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
> >
> > On 13/08/2014 15:11, peter dalgaard wrote:
> > > This isn't unique to tcltk. Anything that blocks the keyboard loop
> > blocks the help browser too. Try e.g. opening the help for ls, type
> > Sys.sleep(15) and watch the beach ball in the help browser as you try
> > to scroll in it.
> >
> > But Sys.sleep should not be blocking an event loop: from its help
> >
> > The intention is that this function suspends execution of R
> > expressions but wakes the process up often enough to respond to
> > GUI events, typically every 0.5 seconds.
> >
> > The mechanisms to mesh event loops which are in place for Sys.sleep
> > are
> > R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers.
> >
> > Note that the help for tkwait says (on my box)
> >
> > While the tkwait command is waiting it processes events in
> > the
> > normal
> > fashion, so the application will continue to respond to user
> > interac-
> > tions. If an event handler invokes tkwait again, the
> nested
> > call to
> > tkwait must complete before the outer call can complete.
> >
> > but as this is X11 Tk, it means X11/Unix events. You can demonstrate
> > that, as e.g the http server still works (use help.start() first).
> >
> >
> > > -pd
> > >
> > >
> > > On 13 Aug 2014, at 15:14 , John Fox <jfox at mcmaster.ca> wrote:
> > >
> > >> Dear Simon,
> > >>
> > >> Here's a simple script that will demonstrate the problem:
> > >>
> > >> ----- snip -----
> > >>
> > >> library(tcltk)
> > >>
> > >> top <- tktoplevel()
> > >> button <- ttkbutton(top, text="help", command=function()
> > print(help(lm)))
> > >> tkgrid(button)
> > >> tkwait.window(top)
> > >>
> > >> ----- snip -----
> > >>
> > >> The problem is produced by tkwait.window(), and this call is in
> all
> > Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause
> > problems, but obviously it's causing this problem. I'm also not
> > certain whether calling tkwait.windows() is necessary and will look
> > into the consequences of removing it -- I believe that it's been
> there
> > for many years, from the earliest versions of the Rcmdr.
> > >>
> > >> With respect to changing using preferences, this is done only
> until
> > the Commander() exits. If getting rid of the call to tkwait.window()
> > proves problematic, I can ask the user for permission in a pop-up
> > dialog.
> > >>
> > >> Thanks for your help,
> > >> John
> > >>
> > >> On Wed, 13 Aug 2014 00:25:30 -0400
> > >> Simon Urbanek <simon.urbanek at r-project.org> wrote:
> > >>> John,
> > >>>
> > >>> can't you address the underlying issue instead and don't block
> the
> > event loop? A lot of things don't work if the event loop is blocked
> and
> > I would argue that changing user's preferences behind the scenes is a
> > violation of the CRAN policies.
> > >>> I'm happy to help if you send me a bit more details.
> > >>>
> > >>> Cheers,
> > >>> Simon
> > >>>
> > >>>
> > >>> On Aug 12, 2014, at 6:15 PM, John Fox <jfox at mcmaster.ca> wrote:
> > >>>
> > >>>> Hi Marc,
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Marc Schwartz [mailto:marc_schwartz at me.com]
> > >>>>> Sent: Tuesday, August 12, 2014 5:10 PM
> > >>>>> To: John Fox
> > >>>>> Cc: r-sig-mac at r-project.org
> > >>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
> > >>>>>
> > >>>>> Hi John,
> > >>>>>
> > >>>>> Happy to help. I recalled seeing something previously on this,
> so
> > a
> > >>>>> search using rseek.org was fruitful.
> > >>>>>
> > >>>>> The potential gotcha, of course, is if for some reason the GUI
> > exits in
> > >>>>> a manner possibly not under your control. The setting would not
> > be
> > >>>>> returned to the default and the therefore, as you note,
> retained
> > for a
> > >>>>> subsequent session where the behavior may not be desired.
> > >>>>>
> > >>>>
> > >>>> Yes, there is that possibility.
> > >>>>
> > >>>>> If this is for Rcmdr, perhaps this is something that could be
> > added to
> > >>>>> a menu, where the user can alter the behavior in either
> direction
> > as
> > >>>>> desired, if that makes sense.
> > >>>>>
> > >>>>
> > >>>> As you guessed, this is for the Rcmdr, where the built-in R.app
> > browser
> > >>>> doesn't play well with dialog help buttons -- the browser is
> > unresponsive
> > >>>> until the dialog that called it closes -- while an external
> html-
> > help
> > >>>> browser works fine.
> > >>>>
> > >>>> I've now successfully implemented the approach I outlined, in
> > which the
> > >>>> previous setting is restored when the Commander GUI closes. As
> you
> > point
> > >>>> out, this isn't bullet-proof, but I think it is the best I can
> do
> > for now.
> > >>>> Allowing the user to apply the change would be safer, but users
> > are unlikely
> > >>>> to discover the option.
> > >>>>
> > >>>>> Simon would need to comment on the potential for alternatives.
> > >>>>
> > >>>> Yes, that would be welcome. I still think that a setting via
> > options() would
> > >>>> be better.
> > >>>>
> > >>>> Thanks again for your help,
> > >>>> John
> > >>>>
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Marc
> > >>>>>
> > >>>>>
> > >>>>> On Aug 12, 2014, at 3:46 PM, John Fox <jfox at mcmaster.ca> wrote:
> > >>>>>
> > >>>>>> Hi Marc,
> > >>>>>>
> > >>>>>> Thanks for this. It does work, and I wasn't aware of it --
> > you've
> > >>>>> obviously
> > >>>>>> done a better job than I did of searching for a solution!
> > >>>>>>
> > >>>>>> Although this approach works, it has the disadvantage of
> > permanently
> > >>>>>> changing the help browser in R.app, beyond the current
> session,
> > at
> > >>>>> least
> > >>>>>> until the change is explicitly undone. I think that I can work
> > around
> > >>>>> that
> > >>>>>> by something like
> > >>>>>>
> > >>>>>> current <- system("defaults read org.R-project.R",
> > intern=TRUE)
> > >>>>>>
> > >>>>>> to discover whether the use.external.help preference exists,
> and
> > if
> > >>>>> so, what
> > >>>>>> its value is; to then set the preference to YES if it's NO or
> > unset;
> > >>>>> and
> > >>>>>> finally to remove the preference on exit.
> > >>>>>>
> > >>>>>> Again, thanks -- I think that I can work with this, though it
> > would
> > >>>>> in my
> > >>>>>> opinion be better if the help browser were settable for the
> > current
> > >>>>> session
> > >>>>>> directly via options() in R, or if one could specify the
> browser
> > in a
> > >>>>> call
> > >>>>>> to help().
> > >>>>>>
> > >>>>>> Best (and thanks again),
> > >>>>>> John
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Marc Schwartz [mailto:marc_schwartz at me.com]
> > >>>>>>> Sent: Tuesday, August 12, 2014 4:04 PM
> > >>>>>>> To: John Fox
> > >>>>>>> Cc: r-sig-mac at r-project.org
> > >>>>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
> > >>>>>>>
> > >>>>>>> On Aug 12, 2014, at 2:33 PM, John Fox <jfox at mcmaster.ca>
> wrote:
> > >>>>>>>
> > >>>>>>>> Dear list members,
> > >>>>>>>>
> > >>>>>>>> Is there a way to bypass the R.app help browser, and to use
> > instead
> > >>>>>>> an alternative browser, such as the one pointed to by
> > >>>>>>> getOption("browser")?
> > >>>>>>>>
> > >>>>>>>> I've tried a number of strategies, including setting
> > .Platform$GUI
> > >>>>> <-
> > >>>>>>> "unknown". The only approach I tried that works is to mask
> the
> > >>>>> help()
> > >>>>>>> function with a modified version, but this produces other
> > problems,
> > >>>>>>> such as referencing unexported objects from utils and tools.
> > >>>>>>>>
> > >>>>>>>> It would be nice if the help() function had a browser
> > argument,
> > >>>>>>> similar to that in browseURL(), and defaulting to the current
> > >>>>>>> behaviour.
> > >>>>>>>>
> > >>>>>>>> Any suggestions would be appreciated.
> > >>>>>>>>
> > >>>>>>>> John
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> John,
> > >>>>>>>
> > >>>>>>> I found this post from Simon that seems to work:
> > >>>>>>>
> > >>>>>>> https://stat.ethz.ch/pipermail/r-sig-mac/2009-
> > December/006908.html
> > >>>>>>>
> > >>>>>>> I tried it on my Mac in the latest version of R.app, which I
> > >>>>> normally
> > >>>>>>> do not use and the help system does now popup a browser.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>>
> > >>>>>>> Marc Schwartz
> > >>>>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> R-SIG-Mac mailing list
> > >>>> R-SIG-Mac at r-project.org
> > >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> > >>>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> R-SIG-Mac mailing list
> > >> R-SIG-Mac at r-project.org
> > >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> > >
> >
> >
> > --
> > Brian D. Ripley, ripley at stats.ox.ac.uk
> > Emeritus Professor of Applied Statistics, University of Oxford
> > 1 South Parks Road, Oxford OX1 3TG, UK
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
More information about the R-SIG-Mac
mailing list