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

From: Duncan Murdoch <>
Date: Tue 30 Nov 2004 - 23:00:00 EST

On Tue, 30 Nov 2004 12:27:03 +0100, Martin Maechler <> wrote:

>{I have changed the subject to match this interesting side thread}
>>>>>> "TL" == Thomas Lumley <>
>>>>>> 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 mailing list Received on Tue Nov 30 23:11:16 2004

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