hania@DECWRL.DEC.COM (10/20/87)
There has been a lot of discussion here recently about how applications should go about resizing or moving themselves: should they issue the appropriate X call, or should they just change one of the standard properties, and expect the window manager to take care of their request? Here is our view. First off, we believe that applications should avoid initiating geometry operations. Our view is that window placement and size are best left in the control of the user and his window mananger. We realize, however, that there may be times (yuck, phooey!!) when it may be appropriate for an application to want to change its geometry. In those cases...: Applications should work correctly under the assumption that no window manager is running. This means that, if there is an X call which would satisfy the application's request, the application *must* issue that call. (We will address the problem of what to do about requests to the window manager for which no X calls exist in a separate message). Thus, if an application wants to map itself, it issues a Map request; if it wants to move itself, it issues a Configure request. In order to work correctly with some window managers (in particular, window managers which reparent application windows, or window managers which provide zooming operations), an application should *also* set the properties to reflect what it wants to happen. This makes it possible to avoid some race conditions which would otherwise occur, and provides simpler semantics for the move operation with reparenting window managers (assuming y'all agree to the proposed semantics, below). Specifically, our protocol for an application to follow when it wants to change its geometry (assuming it's in the normal state) is: 1. Grab the server. 2. Call XGetNormalHints . 3. Set the x, y, and width, height fields of the hints structure as appropriate; augment the flags field. The x and y values should be in root coordinates, not parent coordinates. 4. Call XSetNormalHints AND reconfigure the window with an explicit Xlib call. 5. Ungrab the server. 6. Don't assume you've been resized until you get a configure notify. In order to play by these rules, window managers must do one of the following: 1. Ignore the size and position requests made via hints, and either don't allow applications to resize or move themselves at all, or allow them to change size and position using the configure call. "uwm" is such a window manager, and, as such, has no other obligations. 2. Honor (or at least notice) the size and position requests made via hints, and respond to them. "Responding" means either maintaining the hints to reflect the true size and position of the window, or invalidating the hints after reading them (by setting the corresponding value_mask bits to 0). This way, when applications change other fields in the size hints, the window manager won't erroneously move a window to some old position when the application is merely trying to change the minimum width, say. Applications should get, augment, and set the hints, as described above, rather than just setting the fields of interest. Otherwise, a race condition might result with the application setting the size hints, for example, and then setting the position hints (and thereby wiping out the size hints) before the window manager has processed the size change request. What follows from this protocol is that window managers should expect applications always to make geometry requests using *both* hints and direct X calls, and therefore should not attach any special meaning to requests issued using both methods. On the other hand, applications should not make assumptions about whether or not a window manager is running. Since configure requests are redirectable, applications should not assume that their size has changed until they receive a configure notify event from the server. Hania Gajewska and Mark Manasse Digital Equipment Corporation Palo Alto, CA