Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!ames!sdcsvax!ucbvax!DECWRL.DEC.COM!hania
From: hania@DECWRL.DEC.COM
Newsgroups: comp.windows.x
Subject: Re:  window manager property semantics
Message-ID: <8710121951.AA07166@gilroy.dec.com>
Date: Mon, 12-Oct-87 18:05:54 EDT
Article-I.D.: gilroy.8710121951.AA07166
Posted: Mon Oct 12 18:05:54 1987
Date-Received: Wed, 14-Oct-87 02:06:08 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 75

As designer of the set of properties for use by window managers, I feel
obliged to respond to the recent voluminous traffic on the subject of
how they should be used.  Ellis Cohen points out the lack of a document
which would guide application writers (and window manager writers) in
the "proper" use of these properties.  I think that such a document is
badly needed, and I take blame for the fact that it has not yet been
posted to this group.  Here at Digital, we have such a document for our
application writers; it contains some DEC-specific stuff, but I promise
to edit it and post it before the end of the month.

I was delighted to see the posting by Adam de Boor; his message
reflects almost exactly our views on how the properties should be used,
and our philosophy of window management in X in general -- thank you,
Adam.  I was encouraged to see that it was possible to come to the
correct conclusions about X window management based on the minimal
documentation available in the Xlib document.  Similarly, the meassage
from Robert Scheifler is also, as you would expect, right on track.  On
the other hand, we disagree with the philosophy posted by Ellis Cohen;
we feel that it represents a very narrow view of window management, and
does not fit with the X philosophy.

At the core of the X philosophy is that ALL APLLICATIONS SHOULD "WORK"
WITH ALL WINDOW MANAGERS OR WITH NO WINDOW MANAGER AT ALL.  They may
work better with some window managers than with others, but they should
never be written in such a way that they would break altogether unless
a window manager behaved a certain way.  Mr. Cohen proposes that
applications should never map their top-level window; we feel this is
WRONG, WRONG, WRONG.  We understand that the Siemens window manager
expects this behavior; we believe that is also wrong.  There is a
mechanism in X to provide notification from a client to a window
manager that the client wants to map its top-level window; this
mechanism is called Substructure Redirect.  We believe that window
managers should rely on this mechanism for notification of windows
wanting to be mapped, and not invent their own, roughly equivalent in
power, protocol.

Mr. Cohen writes in his latest message:

>Suppose that WM_HINTS indicates that the initial state should be iconic, and
>the icon is provided (via WM_HINTS) as a pixmap (rather than as a separate
>icon window).  There is nothing for the application to map!  The application
>can't map the main window since the initial state is supposed to be iconic.
>The application can't map the icon window, since there is no icon window

The falacy in reasoning that results in the conflict about which window
an application should map -- its main window or its icon window -- when
it wants to come up iconic is the belief that it's the application,
rather than the window manager, that makes this decision.  Consider the
following scenario instead: the application sets up all the hints it
wants, then issues a Map Request.  The window manager intercepts this
request, notices that the application wants to come up iconic, and
(assuming it is happy with this) creates and maps the application's
icon window (but does not map the application's main window).  This may
not always result in the behavior the user wants -- some window
managers may not obey the hint that the application should come up
iconic -- but at least it will not break the application by failing to
map it altogether.

Again, I promise to post a message soon describing how these properties
were intended to be used when we designed them.

Finally, I would like to clarify some definitions that have been irking
me since this discussion started: what makes a window manager "smart"
or "dumb", and how is a user supposed to know which kind he is running
(so that he can set Mr. Cohen's proposed flags appropriately)?  I
expect that there will be many excellent window managers written that
will not behave the way Mr. Cohen suggests they should; we've been
calling all these window manager "dumb".  On the other hand, there may
be some bad window managers written that obey Mr. Cohens rules for
window managers; these are "smart" window managers.  Since I don't
believe many of Mr. Cohen's suggestions, I am hard at work on a dumb
window manager.  I hope all of you are writing the kind of dumb
applications that will work well with it or without it.

   Hania