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

From: Paul Murrell <p.murrell_at_auckland.ac.nz>
Date: Wed 01 Dec 2004 - 06:55:27 EST

Hi

Duncan Murdoch wrote:

> On Tue, 30 Nov 2004 12:27:03 +0100, Martin Maechler
> <maechler@stat.math.ethz.ch> wrote:
> 
> 

>>{I have changed the subject to match this interesting side thread}
>>
>>
>>>>>>>"TL" == Thomas Lumley <tlumley@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@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Wed Dec 01 07:00:10 2004

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