From p.murrell at auckland.ac.nz  Tue Nov 30 22:32:57 2004
From: p.murrell at auckland.ac.nz (Paul Murrell)
Date: Tue Nov 30 22:32:30 2004
Subject: [Rd] pausing between plots - waiting for graphics input
References: <b68812e704112708422b5228a4@mail.gmail.com>	<1101582479.13352.37.camel@horizons.localdomain>	<b68812e704112718032d3cf7d8@mail.gmail.com>	<vuhiq095lke0trblge8161b3dakaubg776@4ax.com>	<2kpjq0p9bq1i8b2258rl71bds4k9bg83fq@4ax.com>	<Pine.A41.4.61b.0411290912110.88302@homer09.u.washington.edu>	<16812.22791.971545.79304@gargle.gargle.HOWL>
	<jrnoq05l7bk577i9agfjctgh8k2jq8ls7m@4ax.com>
	<41ACD02F.4000105@stat.auckland.ac.nz>
	<rdmpq0p3b38fk1vupird057t7bnha2kf5f@4ax.com>
Message-ID: <41ACE709.1090205@stat.auckland.ac.nz>

Hi


Duncan Murdoch wrote:
> On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell
> <p.murrell@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@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/


[Rd] pausing between plots - waiting for graphics input
Paul Murrell