[Rd] pausing between plots - waiting for graphics input

[Uwe Ligges]

Duncan,

I'm a bit late on this topic, but I'd like to bring up two points that I 
find inconvenient / buggy in the current behaviour of R-devel:

1) I'm never looking at the windows()'s title, hence I don't see that I 
should press/klick anything. Also, I'm almost never looking at the 
status line (and in SDI mode there is no status line anyway).
So, I'd like to see a message in the Console as well.

2) Let's enter
  par(ask = TRUE)
  plot(1:10)
and now switch back to the console and hit "Esc" (instead of going to 
the next plot) leaves the Windows device in the state asking for user 
interaction, but it does not respond to any interaction (as expected).


Uwe


Duncan Murdoch wrote:

> 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
> 
> ______________________________________________
> R-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel