[Rd] pausing between plots - waiting for graphics input

[Duncan Murdoch]

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.

Duncan Murdoch