Hi
Duncan Murdoch wrote:
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> On Sun, 28 Nov 2004, Duncan Murdoch wrote:"TL" == Thomas Lumley <[EMAIL PROTECTED]> on Mon, 29 Nov 2004 09:15:27 -0800 (PST) writes:
>> >> 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 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/
______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
