Re: [Rd] pausing between plots - waiting for graphics input

From: Paul Murrell <>
Date: Wed 01 Dec 2004 - 08:32:57 EST


Duncan Murdoch wrote:
> On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell
> <> 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.
>>It would presumably be not too difficult to implement something modal 
>>(like dev_locator) - in effect, a dev_eventloop, which blocks the 
>>command line and processes events (both mouse clicks and key strokes) in 
>>a particular graphics window until a prearranged event to quit.  Nasty 
>>modal behaviour, but doable and obviously useful in some ways.  Any 
>>interest in that?

> You mean something like this?


> The user sees a function
> graphevents <- function(handler, events = c('mousedown', 'mouseup',
> 'mousemove', 'keydown', 'keyup') , prompt = 'Please do something')
> which calls the handler function with a standard set of args
> indicating what event just happened and keeps going until the handler
> returns some non-NULL value. So locating a single point could be
> implemented as
> onmousedown <- function(event, button, x, y) {
> c(x,y)
> }
> graphevents(onmousedown, events='mousedown', prompt='Click on the
> graph')
> and waiting for the user to hit a key could be implemented as
> onkeyup <- function(event, key) {
> }
> graphevents(onkeyup, events='keyup', prompt='Hit any key')
> If we wanted both, maybe we could have
> graphevents( list(onmousedown, onkeyup), c('mousedown', 'keyup'))
> That would be fairly easy to implement in the windows() device, but I
> have no idea if it would make sense in other interactive devices.
> Issues would be defining what sort of values "key" would take, what
> events to allow handlers for, what the event handler arg lists would
> look like, and so on. A test of whether it was good enough might be
> whether locator() could be rewritten in R.

We could aim for a pretty conservative subset to ensure cross-platformedness and still gain a LOT more compared to the current capture-mouse-click-only. Things like Java's KeyEvent could provide some nice templates to follow.


>>A much nicer solution of course would be asynchronous event handling in 
>>the graphics window (i.e., you don't block the command line), but that 
>>depends on the event loop integration problem being solved and that does 
>>not look like happening soon.

> Yes, definitely harder.
> Duncan
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
New Zealand
64 9 3737599 x85392

______________________________________________ mailing list
Received on Wed Dec 01 08:37:22 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:01:55 EST