[Rd] pausing between plots - waiting for graphics input

[Paul Murrell]

Hi


Duncan Murdoch wrote:
> On Tue, 30 Nov 2004 12:27:03 +0100, Martin Maechler
> <maechler at stat.math.ethz.ch> wrote:
> 
> 
>>{I have changed the subject to match this interesting side thread}
>>
>>
>>>>>>>"TL" == Thomas Lumley <tlumley at u.washington.edu>
>>>>>>>    on Mon, 29 Nov 2004 09:15:27 -0800 (PST) writes:
>>>>>>
>>   TL> On Sun, 28 Nov 2004, Duncan Murdoch wrote:
>>   >> 
>>   >> Another that deals only with the original graphics problem is to have
>>   >> par(ask=T) wait for input to the graphics window, rather than to the
>>   >> console.  This has the advantage that the graphics window probably has
>>   >> the focus, so a simple Enter there could satisfy it.
>>   >> 
>>
>>   TL> I like this one.  I have often found it irritating that
>>   TL> I have to switch the focus back to the console (which
>>   TL> means uncovering the console window) to get the next
>>   TL> graph.
>>
>>I agree. 
>>Note that this is not windows-specific really.  Rather, this
>>should be applicable to all devices which support minimal mouse
>>interaction, i.e. at least those that support locator(),
>>ideally just all those listed in  dev.interactive
>>
>>However, I'm not at all sure that this should be done with  
>>par(ask = TRUE)  which works on all devices, not just
>>interactive ones.
>>Rather, we probably should a new par() {and gpar() for grid !}
>>option for the new feature,
>>maybe something like [g]par(wait_mouseclick = TRUE)
> 
> 
> If we add a new par(), then none of the existing examples will work
> with it, so we'll get inconsistent behaviour and it will be really
> irritating.
> 
> I think the cleanest way to implement this would be to add a new
> standard graphics driver function that stops to wait for the user, and
> use the existing NewFrameConfirm or equivalent as a default.  However,
> I'm going to try a more roundabout implementation just for the Windows
> device first, just to see if I like it.


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?

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.

Paul
-- 
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/