On Tue, 30 Nov 2004 12:27:03 +0100, Martin Maechler
<[EMAIL PROTECTED]> wrote:
>{I have changed the subject to match this interesting side thread}
>
>>>>>> "TL" == Thomas Lumley <[EMAIL PROTECTED]>
>>>>>> 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
______________________________________________
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
