pete@jwgibbs.cchem (Pete Goodeve) (03/22/91)
There's something I'm missing regarding the management of keyboard
focus in the presence of a manager. I have a program in which I want
to switch focus back to the terminal window from which the program
is running (away from the work window the program itself has created)
so that the user can type in some new parameters; the switch is triggered
by some event in the main window (mouse-click or key-press). (...Okay,
I know that the "proper" way to do it would be to pop up a dialog window
using one of the toolkits, but this program is a conversion from an old
X10 one, and I'm trying to keep it as close as I can to the original
for now.)
My expectation was that I could do XGetInputFocus BEFORE I opened any
window from the program, and acquire the ID of the terminal window, as
that must surely be the one with the current focus, no? Then, when the
program wanted K/B input, it would simply issue XSetInputFocus to that
window until input was complete.
Well, I get a window ID alright, but trying to change the focus to it
has absolutely no effect! Also the ID I get doesn't seem to be that
of the terminal window itself, but rather its window-manager-decorated
parent! So what's up? I should say that I'm doing most of my work on an
IBM RISC/320 running mwm and aixterm, but i seem to get similar effects on
the DEC 5000 the program will normally be at home on. (I'm only mildly
interested in portability...!) Are there any ways to achieve my intention
besides the one I've tried?
(I should also add that I have no trouble setting the focus to my own
window. mwm by default seems to do that automatically -- even for windows
that I don't WANT to send input to -- so I set the XWMHints.input field
False, and do XSetInputFocus myself. That works fine.)
Any pointers appreciated.
--Pete --dshr@eng.sun.COM (David Rosenthal) (03/22/91)
> There's something I'm missing regarding the management of keyboard > focus in the presence of a manager. I have a program in which I want > to switch focus back to the terminal window from which the program > is running (away from the work window the program itself has created) > so that the user can type in some new parameters; the switch is triggered > by some event in the main window (mouse-click or key-press). (...Okay, > I know that the "proper" way to do it would be to pop up a dialog window > using one of the toolkits, but this program is a conversion from an old > X10 one, and I'm trying to keep it as close as I can to the original > for now.) > The ICCCM Section 4.1.7 [page 524 of the Digital Press 2nd edition] describes four possible models of input focus handling for non-window-manager clients. They all assume that if a client sets the input focus, it does so to a window that it itself owns. This should probably be stated explicitly. Attempts by one client to set the input focus to a window belonging to another client are unlikely to succeed - you are attempting to usurp the functions of the window manager, and you are trying to wire in to your program details of the way a particular window manager works. I'm afraid that you will have to make the effort to do it the proper way. David.
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/24/91)
(In passing, something seems to be wrong with your local news software. In particular, your From: line was From: pete@jwgibbs.cchem (Pete Goodeve) which is pretty much useless. I guessed the berkeley.edu from the Organization: line.) > There's something I'm missing regarding the management of keyboard > focus in the presence of a manager. I have a program in which I want > to switch focus back to the terminal window from which the program is > running There may be no such window. The program could have been started from a remote machine via rsh or from a window manager menu. Or it could have been started from a terminal emulator which has since been shut down. Or the emulator could be iconified, etc (you get the idea). > (away from the work window the program itself has created) so that > the user can type in some new parameters; the switch is triggered by > some event in the main window (mouse-click or key-press). The proper solution is, as you say, to do it via some window in your own application. (Whether this window is a popup or not is more or less irrelevant to the issue of setting focus.) > My expectation was that I could do XGetInputFocus BEFORE I opened any > window from the program, and acquire the ID of the terminal window, > as that must surely be the one with the current focus, no? If it exists, it probably is, at that time. This is not certain, though; input focus could be PointerRoot rather than a window. > Then, when the program wanted K/B input, it would simply issue > XSetInputFocus to that window until input was complete. > Well, I get a window ID alright, but trying to change the focus to it > has absolutely no effect! More likely it does what you want it to, but the window manager immediately sets it back to where its keyboard focus policy indicates it should be. > Also the ID I get doesn't seem to be that of the terminal window > itself, but rather its window-manager-decorated parent! Quite possibly. It seems slightly odd to me, but I can't really call it wrong. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu