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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
Hi Marc,
-----Original Message-----
From: Marc Schwartz [mailto:[email protected]]
Sent: Tuesday, August 12, 2014 5:10 PM
To: John Fox
Cc: [email protected]
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 <[email protected]> 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:[email protected]]
Sent: Tuesday, August 12, 2014 4:04 PM
To: John Fox
Cc: [email protected]
Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
On Aug 12, 2014, at 2:33 PM, John Fox <[email protected]> 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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [email protected]
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
