deboor@dill.Berkeley.EDU.berkeley.edu (Adam R de Boor) (10/08/87)
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?
aRWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (10/08/87)
I agree with Adam, clients should be written in such a fashion that they work well even if no window manager is present, without hassle to the user. Clients should definitely use MapWindow to get the window mapped initially, and window managers should use this as the cue that the window is "ready for prime time". The issue of whether clients should thereafter reconfigure of their own volition is a religious one, but I think the reality is that some clients will do just that, so a window manager that cares should protect its real-estate by judicious use of SubstructureRedirect (which is, after all, there for a reason).
rich@DECWRL.DEC.COM (Richard L. Hyde) (10/08/87)
Several people have differnet views as to how clients should interact with intelligent window managers. Rather than express my views in this letter I would point out that the code I wrote as part of the Intrinsics of the Xtk toolkit on the X.V11R1 does what I believe is the proper thing for clients. It handles the cases of smart, stupid, or non-existent window manager. The code is in the module Initialize.c Rich
ellis@cadillac.siemens.COM (Ellis Cohen) (10/12/87)
dill.Berkeley.EDU!deboor@ucbvax.berkeley.edu (Adam R de Boor) writes > 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. We believe that the window manager should map when it sees the WM_HINTS property set. Here's why. 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 (well, actually, the window manager creates an icon window in which to display the pixmap, but the application has no knowledge of it). Since WM_HINTS will cause the icon to be opened by the window manager in this case, consistency seems to dictate that setting WM_HINTS should produce the initial state, no matter what it is. If the initial state is not iconic, or is iconic, but there is an icon window provided, we could wait for it to be mapped, but we think that's not consistent. Since other window managers may disagree with this point of view, the safest approach is to set the WM_HINTS after all the other hints, and (unless you want an initial icon specified via a pixmap), follow it immediately by a Map. > 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. XConfigureWindow is safer, but is really a heavy handed approach. WM_NORMAL_HINTS allows the client to distinguish between size hints specified by the application and those specified (to the application) by the user. This is an important distinction, and is used by our window manager. In a posting real soon now, I'll explain what we think this distinction is about and how both clients and window managers should treat it. > Summary: I believe applications should be written to work equally well (or > perhaps better) with a window-manager as without one. The truth of the matter is that there will inevitably be a window manager present. Real soon now, there will be a variety of intelligent ones to choose from, and it will make sense for applications to interact with them appropriately. We're in a transition now, where there are no good window managers generally available, and yet people want their applications to run. Still, I think application writers should write their applications so that when good window managers are available, the application will work correctly with them. I think that means that applications should use a switch to mean "dumb or no manager", since in 6-9 months, that will be a special case.
dshr@SUN.COM (David Rosenthal) (10/12/87)
I strongly support Adam's note deprecating the use of properties as
commands to the window manager to map and resize windows. The clinching
argument (which Adam omitted) is that the use of properties in this way
assumes infinitely reliable window managers. The use of a command-line
argument, or a property on the root window, as a way of finding out
if a window manager is running, is obviously bogus; it tells you either
that the user thinks that a window manager is running, or that a window
manager once ran. The way to do it is to examine the all-event-masks
field returned by GetWindowAttributes. But using this means an extra
round-trip on every window manipulation, and STILL leaves you with a
window of vulnerability in which the window manager can vanish, and
the application will do the wrong thing:
GetWindowAttributes(&foo) /*Start Window of vulnerability */
if (foo.all_event_mask & (SubstructureRedirect|CreateNotify|...) {
/*Window manager is running */
ChangeProperty()
} else {
/*No window manager*/
MapWindow()
}
/* End window of vulnerability */
Making all window manipulations look like this would be really intolerable.
As I see it, the ONLY case in which an application should not explicitly
size & map its window is the case of an application that wants to start
iconinc, but does not have an icon window. The behaviour of iconic things
that don't have a window is entirely up to the window manager, but I don't regard
this as an argument for the application not sizing & mapping, it is rather
an argument that if the application really wants to start iconic, it had better
have an icon window (and size and map it ......).
David.gancarz@decvax.UUCP (Mike Gancarz) (10/12/87)
In article <> ellis@cadillac.siemens.COM (Ellis Cohen) writes: >> Summary: I believe applications should be written to work equally well (or >> perhaps better) with a window-manager as without one. > >The truth of the matter is that there will inevitably be a window manager >present. Real soon now, there will be a variety of intelligent ones to >choose from, and it will make sense for applications to interact with them >appropriately. We're in a transition now, where there are no good window >managers generally available, and yet people want their applications to run. There is no guarantee that a window manager will be present. Suppose the window manager only runs when the user initiates some action? One of those already exists under X10 and is used by most people here. (At least the ones still running X10!) I could imagine a window manager run by a clock, too. X is a system that encourages people to change user interfaces to suit the task at hand. Those interfaces won't necessarily reflect your view of the world. >Still, I think application writers should write their applications so that >when good window managers are available, the application will work correctly >with them. I think that means that applications should use a switch to mean >"dumb or no manager", since in 6-9 months, that will be a special case. Since there are likely to be far more applications around than window managers, application writers are going to do whatever suits them. The most effective window managers will be those that are flexible enough to be used with the greatest number of applications. And remember that, as use of X becomes more widespread, not all applications writers will be X-perts. The most useful window managers will be the ones that are the most forgiving. Adding a switch to every application seems silly. The software should be smart enough to figure that out on its own. Better yet, it shouldn't care. That's what all the extra event crud in X11 is for. By the way, *good* window managers are already available under X11. When *different* window managers come along, I'll be happy to give them a spin. After all, variety is the spice of life. --Mike
hania@DECWRL.DEC.COM (10/13/87)
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
ellis@cadillac.siemens.COM (Ellis Cohen) (10/13/87)
Adam R de Boor <deboor%buddy.Berkeley.EDU@berkeley.edu> writes > I am curious: how do you detect the setting of the WM_HINTS property of a > window you don't know exists? Once the manager knows the window exists, it > can select PropertyNotify on the window, but unless the client has mapped or > configured the top-level window, the window manager won't know about it... Well, we select SubstructureNotify on the parent window. That way, when the parent is CREATED (not mapped) in the root, we get a CreateNotify event. That's when we select PropertyNotify. > As for the iconic state: if there is no window manager present, it is rather > silly for an application to start out iconic, even if the user tells it to, > because, unless it has special hooks like xterm (v10) to de-iconify itself, > an iconified application will stay that way until the user starts a window > manager, or kills the application. Since a window manager needn't actually > map a window when it receives the MapRequest event, but could, in fact, create > and map an icon window with the specified icon pixmap, I again say the window > manager should leave the window alone until it is mapped. The mapping of the > main window signifies that the application is completely set up. Well, you raise an interesting point here. I suppose it is possible for the window manager to treat the initial request to map the main window as an indication that the initial state (i.e. normal, zoomed, iconic, inactive) should be produced. That is indeed a reasonable alternative. We have chosen though, to treat WM_HINTS more actively. For example, in our window manager, the client can hint (through WM_HINTS) that the state should be changed from Normal to Zoomed, and the window manager will Zoom the window. Using the initial setting of WM_HINTS to open the window or icon is more consistent with that model. I think the real issue though, is that we believe that Map and Configure are low-level operations, and should not directly be used by applications. For main windows, we think that applications should use hints instead. For subwindows, we think that applications should generally use the operations provided by toolkits instead. Ellis Cohen Siemens RTL Tiled Window Project (609) 734-6524 ellis.cohen@a.gp.cs.cmu.edu
ellis@cadillac.siemens.COM (Ellis Cohen) (10/13/87)
decvax!gancarz@ucbvax.berkeley.edu (Mike Gancarz) writes > There is no guarantee that a window manager will be present. Suppose > the window manager only runs when the user initiates some action? One > of those already exists under X10 and is used by most people here. (At > least the ones still running X10!) I could imagine a window manager run > by a clock, too. X is a system that encourages people to change user > interfaces to suit the task at hand. Those interfaces won't necessarily > reflect your view of the world. In X10, there was no redirection of events. Consequently, every application had to include support for moving, resizing, and iconizing windows. This was seen to be a bad thing. In X11, the model generally assumes that applications will no longer do these things, and that a window manager will do them instead. This is indeed true of the rewritten applications that come on the release tape. In other words, if you want to be able to move, resize, or iconize windows, you will need to have a window manager running. Now, I can believe that specialized applications will take over the entire screen and explicitly map and reconfigure windows itself, but in the ordinary case, with independent clients, there will be a window manager present! > Since there are likely to be far more applications around than window > managers, application writers are going to do whatever suits them. The > most effective window managers will be those that are flexible enough to > be used with the greatest number of applications. And remember that, as > use of X becomes more widespread, not all applications writers will be > X-perts. The most useful window managers will be the ones that are the > most forgiving. I agree, but ... The real problem is that X11 is young, and just doesn't have a user manual yet. I know of no window manager in which writing window applications is trivial. All of them come with manuals that show a sample application which initializes the window and waits for events. When X comes of age, and there is a manual which has such an example, this will not be a problem. Perhaps the problem is also that there is (legitimate) disagreement about how hints should be used. As others have noted, it was more important to get X11 out than to solve all of its problems, and HINTS were certainly an area that needed and still need more work. In time...