[Rd] pausing between plots - waiting for graphics input
Duncan Murdoch
murdoch at stats.uwo.ca
Thu Dec 9 19:55:05 CET 2004
On Wed, 01 Dec 2004 10:32:57 +1300, Paul Murrell
<p.murrell at auckland.ac.nz> wrote :
>Hi
>
>
>Duncan Murdoch wrote:
>> On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell
>> <p.murrell at auckland.ac.nz> wrote :
>>
>>
>>>This sounds like the general problem of being able to capture keyboard
>>>input on a graphics device (a key-stroke equivalent of dev_locator).
>>>Robert has been keen on this for a while too.
I've now committed the getGraphicsEvent function with mouse and
keyboard support. So far only the windows screen device knows how to
work with it, because that's all I've got. It's in the R-devel build
I just uploaded, which should be downloadable by tomorrow.
If someone wants to write support for other platforms, I'd be happy to
help. I imagine the implementation will change a bit when we do the
first one, because I don't know the other platforms at all, and have
probably made some Windows-centric assumptions. But at least it's a
starting point.
Here's a quick summary of how it currently looks:
The device is assumed to be based on the NewDevDesc structure. There
are new fields canGenXXX to indicate that it can generate mouse or
keyboard events; getGraphicsEvent aborts if you try to set an event on
a device that doesn't support them.
When getGraphicsEvent is active, it sets a gettingEvent field to TRUE,
saves its environment into eventRho, and calls the getEvent callback.
This callback is supposed to run an event loop, looking for user
input. When it sees an event that it is supposed to handle, it calls
a doMouseXXX or doKeybd function, and those translate the message into
an R call to call the handler, and put the result in eventResult.
The whole process can be aborted if the user interrupts (e.g. by
hitting Esc in Rgui); in that case, another callback called onExit is
called to clean up.
Comments are welcome.
Duncan Murdoch
More information about the R-devel
mailing list