[R-SIG-Mac] bypassing the R.app help browser?

[John Fox]

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