[Rd] RAqua and AquaTclTk
jago at mclink.it
Thu Oct 30 22:45:28 MET 2003
On Giovedì, ott 30, 2003, at 17:54 Europe/Rome, Peter Dalgaard wrote:
> Stefano Iacus <jago at mclink.it> writes:
>> While playing around with panther I discovered (with surprise) that
>> tcltk seems to work (even if not smoothly) with RAqua without first
>> calling tkStartGUI.
>> I switched back to 10.2.6 and it works as well.
>> I think this is due to the "last minute" fix in RAqua now using idle
>> timers because of too much cpu usage.
>> Some "mouse" trick is needed though. If you want to test it you can
>> just try
>> press return and wait for quartz device to show the density plot.
>> Then to interact with the widgets just click outside R (everywhere but
>> not windows related to R) and click on the tk-window to activate it.
>> Now you can interact with the widgets for "some time", which means
>> that after a while you loose the control and you need to re-do the
>> trick (click outside R and reactivate the tk window).
>> BTW, doing this (which is far from being even suboptimal) you loose
>> RAqua menus.
>> I think RAqua menus should be reestablished if I force the redrawing
>> after every activation of the RAqua Console window.
>> The other problem (loose of control of tk window) seems to come from
>> the bliking cursor on the RAqua Console.
>> I'll try to change/fix the last two points in R-patched and update you
>> on this history.
>> Of course if you have other ideas in the meanwhile let me know.
> I'm not sure I understand the code, but it seems that you're running
> OtherEventLoops in a separate "thread" (or timer)?
it is not another thread. A timer just fires events to the main
(carbon) event loop.
> InstallEventLoopTimer(GetMainEventLoop(), 0,
> kEventDurationMillisecond*10, NewEventLoopTimerUPP(OtherEventLoops),
> NULL, &Inst_OtherEventLoops);
> and it is OtherEventLoops that does
> R_runHandlers(R_InputHandlers, R_checkActivity(0, 1));
yes, it is strange as this is needed to interact with X11 windows for
> If Tcl is among the R_InputHandlers, I think you might want to do this
> *only* when idle, to avoid getting a callback interfering with an
> executing Tcl command. I.e. perhaps get rid of OtherEventLoops and
> move content into RIdleTimer?
I'm not sure. As far as I understand Idle Timers on Carbon, these works
when the user do not interact with the interface and if I want to
interact with tkwidgets I think I need to leave the code where it is
now. I use idle timers to wake up the event loop queue so that when R
is printing output to the console, the console is refreshed. Otherwise,
I only see the console refreshed if I do something liek moving the
mouse, clicking somewhere etc.
> Another thing that I suspect you're not handling properly is the
> recursive event loop: If you do something like tkwait.variable("foo")
> then the tcltk main loop takes over and you need to register an Aqua
> event handler for it. Can this be done?
I'm not sure I understand you. Can you drop me a couple of lines of
code to see what R is expected to do?
I think I can register something if I know how (I think I reasonable
know the carbon event part, I don't know about the tktcl part of the
> Again, I have zero documentation on how Aqua works and no machine
> where it runs, so I could be talking complete rubbish here...
> O__ ---- Peter Dalgaard Blegdamsvej 3
> c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
More information about the R-devel