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. > 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. > 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? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
