Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!dill.Berkeley.EDU!deboor
From: deboor@dill.Berkeley.EDU.berkeley.edu (Adam R de Boor)
Newsgroups: comp.windows.x
Subject: window manager property semantics
Message-ID: <21197@ucbvax.BERKELEY.EDU>
Date: Wed, 7-Oct-87 23:32:01 EDT
Article-I.D.: ucbvax.21197
Posted: Wed Oct  7 23:32:01 1987
Date-Received: Sat, 10-Oct-87 17:35:42 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: deboor@dill.Berkeley.EDU.UUCP (Adam R de Boor)
Followup-To: Ellis Cohen's articles
Organization: University of California, Berkeley
Lines: 84
Keywords: window-manager, property
Summary: what to use when


	In recent postings, the people at Siemens have shed some light on
the use of the window-manager properties in X11. While I'm glad someone
has finally explained in more detail the meanings of the various
properties, I don't quite agree with their interpretation. Not that it's
wrong, or mine is right, it's just not what I've understood from working
on X11 during the alpha and beta test.

    The way I have programmed clients allows them to run equally well
with or without an intelligent window manager. I do not think a client should
have to examine a property on the root window or check a command-line
argument to see if an intelligent window-manager is operating to take care of
its needs. What it should do, rather, is to set up its main window in such a
way that if a window-manager is running, it will have a clear picture of what
the client would like to have happen, and then act as it would if the window
manager weren't there -- creating and configuring its window as it sees fit --
while at the same time accepting any decisions handed out by the window-manager
by way of ConfigureNotify events, and others of that ilk.

    An example: xman performs the following steps on start-up:
	1) Reads arguments and the user's .Xdefaults file for configuration
	information ("windowGeometry", "font", "iconGeometry", "borderWidth"
	and "iconic" are the ones that concern the window-manager).

	2) Set up a XSizeHints structure based on its own prefered
	geometry (=80x66+0+0) using the font bounding box to calculate the
	width and height in pixels (and the resize increments [width_inc and
	height_inc]).

	3) Adjusts the XSizeHints structure to account for the user-specified
	geometry (setting appropriate US flags in the 'flags' field of the
	XSizeHints structure).

	4) Creates the window with the dimensions it decided based on the
	various geometries.

	5) Once the window is created, it sets the standard properties
	(WM_NAME, WM_ICON_NAME, WM_HINTS (for icon_pixmap) and WM_NORMAL_HINTS)
	then goes ahead and modifies the XWMHints structure to take into
	account the iconGeometry and initial state (Iconic or Normal) the user
	has requested.

At this point it has set the properties that most need setting for
the window manager to be able to cope (it doesn't set the WM_CLASS
property because I ported it during beta test). It then goes ahead
and maps all its subwindows, followed by mapping its main window.
If no window-manager is in operation, the xman window gets mapped where it's
supposed to be and xman is happy. If an intelligent window-manager IS
operating, it receives a MapRequest, reads the various properties from the
window, reconfigures the window to its heart's content (generating a
ConfigureNotify event for the window) and then maps the window for the
client.

Several key points here are:
    1) The window-manager should not mess with a window until it is mapped,
    even if it gets ConfigureRequest events for the window -- if it's not
    mapped, it can't affect the screen so the window-manager has no business
    playing with it.

    2) The application must respond to and accept configurations by other
    clients (i.e. window-managers).

    3) Once a window is mapped an application may reconfigure its window in
    the standard way, but it should not rely on getting its own way. If it
    doesn't, it should NOT get into a war with the window-manager.

Some would say that resizing your window should be done by altering the
WM_NORMAL_HINTS property for the window, but I think that is living
dangerously, as it relies on the window-manager being around and NOTICING
THE CHANGE. A far safer course, it seems to me, is the XConfigureWindow
call, which any intelligent window manager will intercept -- it has to to
maintain control of the screen.

Summary: I believe applications should be written to work equally well (or
perhaps better) with a window-manager as without one. This can best be
accomplished by setting the various window-manager hint properties on a
window and then using regular Xlib calls to communicate with the window-
manager by means of the SubstructureRedirect selection the window-manager
has placed on the root window (or ${WINDOW_PARENT} window...). This is the
safest course.

Arguments?

a