morreale@bierstadt.scd.ucar.EDU (Peter Morreale) (01/12/91)
> > > Section 6.2 of the ICCCM says "In general, clients should not warp the > pointer". More specifically, Section 4.2.7 says "Clients should not warp > the pointer in an attempt to transfer the focus; they should set the > focus and leave the pointer alone". The section then goes on to explain > how to set the focus. Section 4.1.7 gives more details. > > David. > This is true, much to my embarassment..... Then how do we accomplish this type of action? I find it extremely constrictive to have to continuously move the pointer to the next text field in the "entry-form" application that I've built. Allowing the user to completely fill out my template without ever having to move a hand from the keyboard to the mouse is a very desirable feature in my application. How do people do it otherwise? -PWM
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (01/15/91)
> ... How do people do it otherwise?
Use Motif widgets (which have keyboard traversal built in).
---
Benetaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (01/16/91)
> > Allowing the user to completely fill out my template without ever > having to move a hand from the keyboard to the mouse is a very > desirable feature in my application. > > How do people do it otherwise? > >-PWM XtSetKeyboardFocus for Xt users. XSetFocus (I believe) for X users. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
tym@bruce.cs.monash.OZ.AU (Tim MacKenzie) (01/16/91)
In <9101112245.AA25816@bierstadt.scd.ucar.EDU> morreale@bierstadt.scd.ucar.EDU (Peter Morreale) writes: >> Section 6.2 of the ICCCM says "In general, clients should not warp the >> pointer". >> David. > Allowing the user to completely fill out my template without ever > having to move a hand from the keyboard to the mouse is a very > desirable feature in my application. > How do people do it otherwise? I created a sub-class of the AsciiText widget to handle this sort of stuff. It has the extra resources XtNnext and XtNprevious which specify which widget to transfer focus to on Tab/shift Tab. It also switches off the caret when it does not have focus so it is apparent to the user where the focus is. Default resources: DisplayCaret: False Translations: <EnterWindow>: focus-in() <FocusIn>: display-caret(on) <FocusOut>: display-caret(off) Shift<Key>Tab: focus-previous() <Key>Tab: focus-next() focus-(in|next|previous) use XSetInputFocus() to set the focus to the appropriate widget. I guess this could be done without creating a sub-class but it would be a whole lot messier and cumbersome. >-PWM Greetings. Tim MacKenzie tym@bruce.cs.monash.edu.au
toml@ninja.Solbourne.COM (Tom LaStrange) (01/18/91)
> Allowing the user to completely fill out my template without ever > having to move a hand from the keyboard to the mouse is a very > desirable feature in my application. > > How do people do it otherwise? > >-PWM XtSetKeyboardFocus for Xt users. XSetFocus (I believe) for X users. Yes but you must set the appropriate input hints to the window manager before attempting to set input focus within your application. See section 4.1.7 of the ICCCM. -- Tom LaStrange toml@Solbourne.COM
mouse@larry.mcrcim.mcgill.EDU (01/21/91)
>> Section 6.2 of the ICCCM says "In general, clients should not warp >> the pointer". More specifically, Section 4.2.7 says "Clients >> should not warp the pointer in an attempt to transfer the focus; >> they should set the focus and leave the pointer alone". > Then how do we accomplish this type of action? I find it extremely > constrictive to have to continuously move the pointer to the next > text field in the "entry-form" application that I've built. > How do people do it otherwise? For the most part, I suspect they don't. I've seen three programs that use text-input widgets but mishandle this. One of them is a commercial desktop publishing program, one is a privately developed program someone I know is working on; I won't discuss those. The third one is xpostit. (Caveat: I don't know whether this is true of the current xpostit. It was definitely true some months ago when I tried xpostit.) The problem is that when a note (implemented as a distinct top-level window) is given focus by the window manager, keystrokes are nevertheless ignored unless the pointer is inside the window. The other two programs exhibited symptoms with different details, but all of them had the same basic problem: they were depending on the X server to do keyboard event distribution to their various subparts, but they weren't doing this right by setting the focus; instead, they were simply depending on the pointer position to arbitrate at the sub-top-level-window level. Just a plea to try to get app authors to deal with keyboard input properly. (Meaning: test under many different focus paradigms; don't assume that everything's fine just because it works for the developer and a couple of others (who happen to use similar paradigms).) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu