[comp.windows.x] 386i/OpenWindows 2.0/MIT Distrib Problems

mevans@nprdc.navy.mil (Mitch Evans) (01/01/91)

Hello!

	we have a Sun 386i in our office, and I am trying to install some
software on it to help us out.  We are running Open Windows 2.0 from Sun.
The programs that we wish to run are contributed programs from the MIT
X project (like Xfig, and many others).  Our problem is that the programs
compile nicely, but then do not accept input from the keyboard (some do,
some don't).  

	I select the window that the programs appear in, and they do NOT
become the active input window.  I have tried both available properties
options of clicking to get an active window, or just moving the cursor
to make the active window -- neither work.

	If anyone out there knows a way around this problem, I would
appreciate your help.  

					Mitch Evans

P.S.  Where can I get "Imake"?
===============================================================================
|  mevans@nprdc.navy.mil  	      or 	doc@crash.cts.com             |
|  Homebrewers and writers:  The Dream Clinic BBS (619) 670-9522  300-2400bd  |
|  Nothing can compare to a good homebrew...except maybe 2 good homebrews...  |
===============================================================================

mouse@larry.mcrcim.mcgill.EDU (01/01/91)

> [W]e have a Sun 386i in our office, and I am trying to install some
> software on it to help us out.  We are running Open Windows 2.0 from
> Sun.  The programs that we wish to run are contributed programs from
> the MIT X project (like Xfig, and many others).  Our problem is that
> the programs compile nicely, but then do not accept input from the
> keyboard (some do, some don't).

This is undoubtedly the non-ICCCM-compliance problem.  The ICCCM
specifies a way for programs to tell the window manager whether they
are interested in keyboard input, and if so, what model they expect to
use (ie, how they expect to deal with keyboard focus).

The problem is that many programs, particularly those designed for R3,
do not set the hints on their top-level window(s) correctly for this.
I am not sure whether the WM_HINTS property is not being set or whether
it's being set to something incompatible with the ICCCM definition, but
in any case, most window managers seem to deal with this situation as
if the program had claimed to be uninterested in keyboard input.

Some window managers will give a window focus whether it asks for it or
not.  Others, such as (I hear) olwm, are much pickier about this.

The proper fix, of course, is to make the program set its hints
correctly.  If for some reason this cannot be done, it may be possible
to persuade the window manager to give focus to windows even though
they haven't asked for it; at least some of the strict window managers
have some way to tell them to be less strict.  (I don't use such a wm,
so I don't know the details.  Check your documentation.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

envbvs@epb7.lbl.gov (Brian V. Smith) (01/02/91)

< > [W]e have a Sun 386i in our office, and I am trying to install some
< > software on it to help us out.  We are running Open Windows 2.0 from
< > Sun.  The programs that we wish to run are contributed programs from
< > the MIT X project (like Xfig, and many others).  Our problem is that
< > the programs compile nicely, but then do not accept input from the
< > keyboard (some do, some don't).
< 
< This is undoubtedly the non-ICCCM-compliance problem.  The ICCCM
< specifies a way for programs to tell the window manager whether they
< are interested in keyboard input, and if so, what model they expect to
< use (ie, how they expect to deal with keyboard focus).
< 
< The problem is that many programs, particularly those designed for R3,
< do not set the hints on their top-level window(s) correctly for this.
< I am not sure whether the WM_HINTS property is not being set or whether
< it's being set to something incompatible with the ICCCM definition, but
< in any case, most window managers seem to deal with this situation as
< if the program had claimed to be uninterested in keyboard input.

The original poster should get the latest version of xfig; the one that
comes with the contributed software from MIT is very old and isn't ICCCM-
compliant.  The latest version is xfig 2.0 patchlevel 9 and can be gotten
from expo.lcs.mit.edu via anonymous ftp or comp.sources.x.

--
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL; they don't pay me enough for that.

welch@soda.berkeley.edu (Sean N. Welch) (01/02/91)

If you are using olwm from OpenWindows V.2 (and I may be wrong in
assuming that it performs the same way as the one I ftp'd off of 
expo) there should be a resource that can solve your problem with
non-ICCCM compliant clients.  Here's a clip from my .Xresources:

OpenWindows.FocusLenience:      true

And the clip from the man pages here:

     FocusLenience (boolean)
          If this is set to true, olwm will not enforce the ICCCM
          requirement that windows must have the input hint set
          in order to receive the input focus.  This option is
          useful if you run clients that aren't ICCCM-compliant,
          like many X11R3-based clients.  Default value: false.

You'll have to ask elsewhere if you are having the problem with 
another window manager.

Sean Welch
Computer Science Undergraduate Association, University of California, Berkeley