Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: dshr@eng.sun.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: Window manager hints: window group problem
Message-ID: <9102270254.AA14792@devnull.Eng.Sun.COM>
Date: 27 Feb 91 02:38:58 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 56

> We're trying to build an application which has multiple top
> level windows, which we're then trying to group together using
> the window manager hints.  Our goal is that when we iconify the
> "master" window, the other top level window should be iconified
> as well.
> 
You are trying to determine a window manager policy.  The general
window manager may not even have a concept of "iconifying a window".
The ICCCM (Section 4.1.11) specifically leaves it up to the
implementor of a window manager to determine the semantics it
attaches to the group:

	"It is up to the window manager to determine the policy for
	treating the windows in a group."

See also Section 4.1.2.4:

	"Window managers may provide facilities for manipulating the
	group as a whole.  Clients,  at present,  have no way to
	operate on the group as a whole."

Note the word "may",  because it implies also "may not".

> We've run these programs under mwm (1.1), twm, and olwm on X11R4
> on Sun 3 & Sun 4 systems.  Iconifying the first window does not
> iconify the second window.
> 
That is because the implementors of these window managers decided that
their user interface policy did not require that windows in a group
should be inconified/deiconified together.

> Is this a misreading of ICCCM, a bug in the programs, or a problem
> with the window managers?  If it's a problem with the window managers,
> are there any window managers where this works properly?  Is this
> anywhere in the FAQ (I couldn't find it)?
> 
It is a misreading of the ICCCM.  I don't know if there are existing
window managers which implement the policy you want.  You have two
choices:

-	If your application will only be run in a controlled environment
	where you decide which WM gets run,  you can hack on your
	favourite WM and implement the policy you like.

-	If you want your application to work right with the user's
	favourite WM,  you have to live with the fact that you don't know
	what its policy about window groups is (this shouldn't stop
	you providing it with the information about the group,  because
	it will probably do something sensible in the context of its
	overall user interface policy).

I would strongly recommend the second choice - programs that insist on
a particular window manager and a particular user interface to window
management are much to be deprecated.

	David.