coleman@cam.nist.gov (Sean Sheridan Coleman X5672) (01/04/91)
I got a program out of comp.sources.sun called mazewar. I compiled the X version. When I started up the program, and tryed to use the keys asdf to move around, the computer beeped at me and the program did nothing. I tryed to use the dbxtool and put a stop where the program goes when there is a key pressed. When I pressed the 'a' key, I was able to see that the program never even knew a key was pressed. The program compiled correctly. Is it possible that the code is bad or is the OpenWindows implemetation of X bad? I appreciate your help in this matter. Thanks Sean Coleman coleman@bldrdoc.gov [[Ed's Note: Addendum received later. -bdg]] I posted earlier to this group a message about how xmazewar would not accept keyboard input. After a few experiments, I discovered that it works under twm but not olwm. I also discovered that xwebster would not accept keyboard input. Both programs appear to use Xt. Has others seen this and know a solution to the problem
markh@squirrel.labs.tek.com (Mark C. Henderson) (01/05/91)
In article <1060@brchh104.bnr.ca> coleman@cam.nist.gov (Sean Sheridan Coleman X5672) writes:
[[describes problem running a program under olwm]]
-When I pressed the 'a' key, I was able to see that the
-program never even knew a key was pressed.
A solution is to patch states.c in the olwm source. You have to change
the calculation of cli->focusMode around line 730. The problem also
occurs with at least one version of xlife (that is where I first
discovered it). A gross hack that would fix this would be to just always
act as if cli->wmHints->input were always set to true.
You can get the olwm source from xview.ucdavis.edu (it is in the XView 2.0
source there).
Note that mwm explicitly ignores the input hint (there are comments to
that effect in the source code. If you have Motif 1.1 sources around look
at line 832 of WmWinInfo.c in motif/clients/mwm.
Mark C. Henderson, Computer Research Laboratory, Tektronix, Inc.
INTERNET: markh@crl.labs.tek.com (alternate: mchenderson@attmail.com) das@das.harvard.edu (David Steffens) (01/24/91)
In article <1067@brchh104.bnr.ca>, markh@squirrel.labs.tek.com (Mark C. Henderson) writes: > In article <1060@brchh104.bnr.ca> > coleman@cam.nist.gov (Sean Sheridan Coleman X5672) writes: > > [[describes problem running a program under olwm]] > > -When I pressed the 'a' key, I was able to see that the > -program never even knew a key was pressed. > > A solution is to patch states.c in the olwm source.... > A gross hack that would fix this would be to just always > act as if cli->wmHints->input were always set to true. I'll say it's gross. The problem is _not_ in olwm... it's in the X applications which are not ICCCM compliant! See the October issue of _The Sun Software Technical Bulletin_ page 41 for details. Another reference is O'Reilly _X Toolkit Intrinsics Programming Manual_ (Volume 4), section 10.1.4. Fix the broken applications, not olwm! > Note that mwm explicitly ignores the input hint... This doesn't speak well for OSF -- you'd think they of all people would be pushing for ICCCM compliance, too! Furthermore, it leads to a certain amount of confusion. On Athena, if mwm keyboard focus policy is set to "pointer", then all applications receive keyboard focus when started. If, however, mwm keyboard focus policy is set to "explicit", i.e. "click-to-type", and startupKeyFocus is True, then _only_ ICCCM-compliant applications get key focus on startup!