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 <[EMAIL PROTECTED]> wrote :
Paul Murrell <[EMAIL PROTECTED]> 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
______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
