From jago at mclink.it  Thu Oct 30 22:45:28 2003
From: jago at mclink.it (Stefano Iacus)
Date: Fri Oct 31 09:00:25 2003
Subject: [Rd] RAqua and AquaTclTk
In-Reply-To: <x2oevyacpi.fsf@biostat.ku.dk>
Message-ID: <609EBBAA-0B22-11D8-B185-003065CC4CB8@mclink.it>


On Gioved?, ott 30, 2003, at 17:54 Europe/Rome, Peter Dalgaard wrote:

> Stefano Iacus <jago@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
>>
>> library(tcltk)
>> demo(tkdensity)
>>
>> 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.
>
> Stefano,
>
> 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 
example

>
> 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 
history).


> Again, I have zero documentation on how Aqua works and no machine
> where it runs, so I could be talking complete rubbish here...
>
>         -p
>
> -- 
>    O__  ---- Peter Dalgaard             Blegdamsvej 3
>   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N
>  (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
>


[Rd] RAqua and AquaTclTk
Stefano Iacus