Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: eplunix!das@das.harvard.edu (David Steffens)
Newsgroups: comp.sys.sun
Subject: Re: Problems with olwm
Keywords: Windows
Message-ID: <1390@brchh104.bnr.ca>
Date: 23 Jan 91 21:40:41 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 29
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n8, Replies: v10n8
X-Sun-Spots-Digest: Volume 10, Issue 17, message 16
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

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!