ellis@cadillac.siemens.COM (Ellis Cohen) (10/01/87)
USING X PROPERTIES
TO INTERACT WITH WINDOW MANAGERS
AN ABBREVIATED GUIDE
Unfortunately, there is no guide for application writers explaining how
they should use standard X properties to interact with window managers.
We are working on a guide right now, but we thought it would be useful to
provide this abbreviated guide as soon as possible.
In particular, we (of the Tiled Window Project) would like to encourage
"correct" use of X properties, so that window managers, especially those
like ours which manage overall screen layout, don't have to "fight" X
applications.
------------------------------------------------------------
There are really three ways to write an X client
- Assume a manager is running, always! The client does no
XConfigureWindows and does not do the initial XMapWindow. The
properties inform the WM of the proper size and initial state for
the application. The WM, not the client, maps and configures the
client window.
- Do the above, but add a flag (say "-m") to mean "no manager" (or
a dumb manager). Only if the flag is set, should the client do
XConfigureWindows or the initial XMapWindow. Useful with 'uwm'.
- Write code in such a way that it (sort of) works whether or not
there is an intelligent manager. This is our least favorite
alternative. During startup, the client sets the hints, and then
does the XMapWindow in addition. To change size, the client first
does the XConfigureWindow, and then sets the size hints.
------------------------------------------------------------
Our preferred order for initially setting hints is:
- WM_CLASS (name and class of application)
- WM_COMMAND
- WM_CLIENT_MACHINE
- WM_NAME and WM_ICON_NAME
- WM_NORMAL_HINTS
- WM_ZOOM_HINTS (if necessary)
- WM_HINTS
It is very important to set WM_HINTS last! WM_HINTS specifies
the initial state of the window -- i.e. Open Normal, Open Zoomed,
Iconic, or Inactive, and a window manager should do the appropriate
action when it sees the property set. With a window manager present,
you don't need to map the window -- WM_HINTS tells the WM what to do.
If you set WM_HINTS before you set WM_NORMAL_HINTS, then the window
manager will first open the window at some default size, and then, when
it sees WM_NORMAL_HINTS set, it will resize the window. This looks
pretty bad!
If you absolutely feel you must make your application work with dumb
window managers, then explicitly XMapWindow the window after setting all the
hints. If the manager is intelligent, WM_HINTS will already have
opened the window (asuuming you sets its initial state to be open), and
doing a XMapWindow will have no effect.
------------------------------------------------------------
If there is a "real" window manager present, a client shoould change size
by only changing WM_NORMAL_HINTS (or WM_ZOOM_HINTS), not by doing an
explicit XConfigureWindow.
If you absolutely feel you must make your application work with dumb
window managers, then do the XConfigureWindow BEFORE you change
WM_NORMAL_HINTS (or WM_ZOOM_HINTS).
Our window manager treats an XConfigureWindow by the client very
seriously, and tries very hard to do just what is requested. When the
setting of WM_NORMAL_HINTS (or WM_ZOOM_HINTS) is subsequently noted, the
WM doesn't need to do anything, since the hints should already be
satisfied.
If the Hints are set first, the WM may change the window geometry, but
perhaps not exactly as specified (it's only a hint). Then when the
XConfigureWindow is done, the WM will try harder to change the window as
requested. The two redraws look pretty bad.
------------------------------------------------------------
For similar reasons, an application should NEVER resize itself after it
has received a ConfigureNotify indicating that the window manager changed
its size. An application might try to do this because it doesn't like
the size it has been set at. Well, the window manager probably did the
best it could, and the application MUST adapt to the size it has
received. If the client does do a resize, then the window will be
redrawn twice, which is ugly.
Xterm is an example of doing it wrong. It specifies size increments via
WM_NORMAL_HINTS, but if it is not set to a size on an increment boundary,
then it resizes itself. Ideally, a window manager would use the
increment hints, and ensure a "correct size". Unfortunately, this is a
bit complicated to do in our tiled window manager, so we don't support
the increments yet (and besides, they are only a hint!). Xterm should
just adapt by rounding down to the next increment boundary. It doesn't
and behaves badly.
------------------------------------------------------------
Ellis Cohen
(609) 734-6524
ellis.cohen@a.gp.cs.cmu.edu
Mark Biggers
(609) 734-3325
princeton!siemens!biggers
Siemens RTL Tiled Window Projjncedavidh@ucbcad.berkeley.edu (David S. Harrison) (10/01/87)
In article <8709302226.AA01553@audi.siemens.com>, ellis@cadillac.siemens.COM (Ellis Cohen) writes: > If there is a "real" window manager present, a client shoould change size > by only changing WM_NORMAL_HINTS (or WM_ZOOM_HINTS), not by doing an > explicit XConfigureWindow. > > If you absolutely feel you must make your application work with dumb > window managers, then do the XConfigureWindow BEFORE you change > WM_NORMAL_HINTS (or WM_ZOOM_HINTS). Is it possible for the tiled window manager project to suggest a way for an application to automatically determine if a smart window manager is running? Using a special flag when the application is invoked to specify "simple window manager running" is non-intuitive to novice users. Perhaps a standard root window property could be set by an intelligent window manager which could be checked by the application when it starts. David Harrison (davidh@ic.Berkeley.EDU) (...!ucbvax!ucbcad!davidh)