[Rd] pausing between plots - waiting for graphics input

[Duncan Murdoch]

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

>Paul Murrell <p.murrell at 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:

- The graphics window moves to the front
- The graphics menu bar switches to a menu saying "Next"
- The console status line (shown only in MDI mode, I think) says that
the graph is waiting for input
- The graphics window title prompts the user for input.

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