[Rd] pausing between plots - waiting for graphics input

[Paul Murrell]

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.
>>
>>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?


Yes.


> 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) {
>    TRUE
>  }
> 
>  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.

Paul


>>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
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/