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

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: Wed 01 Dec 2004 - 08:22:31 EST

On 30 Nov 2004 21:45:27 +0100, Peter Dalgaard <p.dalgaard@biostat.ku.dk> wrote :

>Paul Murrell <p.murrell@auckland.ac.nz> writes:
>
>> > 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.
>
>We might want to think a bit more carefully about the ergonomics. It
>is actually not very obvious for users to send keypresses to a
>graphics window, unlesse there's a "Press any key" style instruction
>somewhere, and preferably not in a partially obscured console. A
>"Continue" button would be a much more obvious GUI design.

I agree, you need to worry that the user knows you're asking for input. In today's Windows R-devel build, I worked pretty hard to make sure this wouldn't be a problem:

This was just to handle par(ask = TRUE). For the general problem of asking for input from the graph window, I'd say in Windows the 1st and 3rd items above should always happen, the second item is optional (but the regular menu bar should definitely disappear or be disabled), the last should be specified by whoever calls this function to ask for input. However, the conventions on X are different enough that other cues should presumably be used there.  

>> 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?
>
>Sure, but the general structure probably needs a bit of attention.
>There could be different preferred methods for different devices,
>possibly with the current method as a fallback.

Current method? Do you just mean the par(ask = TRUE) behaviour, or is there something more already there?

>> 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.
>
>Not sure we really want that actually. What if someone issues a plot
>command from the command line?

There are definitely lots of issues. In Windows it would be sensible for most event handling to be shut down during function evaluation unless specifically reactivated (but not all; low level stuff like redraws still need to be done). But I understood from discussions last year that X uses a very different event model, so this wouldn't make sense.

Duncan



R-devel@stat.math.ethz.ch mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Wed Dec 01 08:27:28 2004

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