mvh@cfa250.harvard.edu (Mike VanHilst) (11/25/89)
This is an application question about click to focus window managers. I have two programs which interact with each other through a UNIX pipe or VMS mailbox. One program performs data analysis, while the other does image display. In a common situation, the user will type a command in the analysis program's window, starting a process that will request image coordinates interactively using the display. The analysis program sends a request to the display program, at which time the user must indicate the selection by placing the pointer at the appropriate position and striking a key to indicate the specific kind of response. The display program returns the image coordinates and key to the analysis program which then continues operation. This sequence may repeat many times. In the ideal situation, when the display is asked for a position, it warps the pointer into the displayed image (onto the last indicated position should the user wish to perform another operation at the same position). When the user has indicated the selection, the pointer warps back to where it was and everything is as it was before. If, after the mouse was warped into the display window, the user wishes to use another window to get additional information before responding to the display, he/she should not be prevented from doing so (i.e. by XGrab___). How do I make the keyboard focus follow the pointer in this situation without monopolizing it? How can I be sure that the window manager will resume doing whatever it does with focus after the XSetInputFocus()? Is there a standard procedure that will work with all window managers? I should add that the analysis program knows nothing about the window system, nor about the type of program on the pipe (or VMS mailbox) giving it the coordinates. All X calls must be made by the display program. The display program uses only Xlib calls. GENERAL COMMENT ABOUT EXPERIENCE WITH CLICK TO FOCUS WM'S: The display window is an active window; mouse clicking means something in it. With the DECwindows window manager under VMS, the user must click in the window to get focus. This click is also passed on to the window, which then does what it does, assuming that it is a request from the user (moving the software cursor, recentering the image, adjusting the colors, etc.). It is annoying to the user to be requesting focus and end up changing things in the application. I have had to implement a safe, responseless zone, which the users quickly learn to use (following classic behavior mod psychology principles). I don't know any users who like this arrangement. ___________________________________________________________ Mike VanHilst mvh@cfa.harvard.edu Smithsonian Astrophysical Observatory (617)495-7260 60 Garden Street Cambridge, MA 02138
klee@chico.pa.dec.com (Ken Lee) (11/28/89)
In article <1783@cfa241.cfa250.harvard.edu>, mvh@cfa250.harvard.edu (Mike VanHilst) writes: > How do I make the keyboard focus follow the pointer in this > situation without monopolizing it? Section 4.1.7 of the ICCCM discusses requesting your window manager to give one of your windows input focus. This should work with any ICCCM-compliant window manager. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee