hania@DECWRL.DEC.COM (11/17/87)
After extensive discussion with XToolkit implementors and Bob Scheifler, we remembered that the mechanism we specified for communication between window managers and clients was, at best, incomplete. We were also persuaded that making it complete allows us to simplify this mechanism significantly, principallly by getting rid of those nasty server grabs. The main reason we have to change the mechanism we proposed is that we need a way for an application to always know whether and when its geometry request was acted upon, either by a window manager or by the server. Without being able to rely on this knowledge, the application would have to assume that its configure request was denied, and act accordingly. For example, imagine that a bitmap program wants to change the size of its window to display a larger bitmap that it has just read in from a file. The bitmap program would make a reconfigure request, but would have to assume that this request was denied. It might then start repainting its screen to display a clipped version of the bitmap, for instance. When it subsequently receives a configure notify, informing it that its request has been granted, it has to repaint its window again, taking advantage of the larger size. This would cause much unnecessary painting and screen flash. Thus, it would be nice if applications could count on their requests being acknowledged promptly. Communication between window managers and applications would be greatly simplified if it were the case that both were not allowed to modify the same properties. This is because the server grabs that we suggested to avoid race conditions would not be necessary -- the value of a property could not change between the time an application read it and the time it was ready to write it. Our previous proposal suggested that window managers should maintain some state in the size hint properties set by the applications. We shall now introduce another mechanism for window managers to acknowledge the receipt of applications' geometry requests, thereby making it unnecessary for both applications and window managers to modify the same properties. Most of the suggestions proposed in our last message still hold; in fact, applications written using the mechanism described there would not break in the presence of window managers using the mechanism we now propose. But we believe that applications will be more efficient and less complicated when written using the new mechanism we propose here. The new mechanism is as follows: Applications must select for ConfigureNotify on their top-level windows if they ever care about the size or position of those windows. When an application wants to resize or move itself, it issues both a configure request, and a property change, as before. If the window manager agrees to reconfigure the application as requested, it does just that; the application will get a configure notify, and will thus know that it's been reconfigured (and thus that it is now safe to paint into its window, say). If the window manager doesn't want to reconfigure the window as requested, it is obliged to sent a client message to the application. This message will contain WM_CONFIGURE_DENIED as the message type. Thus the application can know that its request has been denied. If there is no window manager running, the application's configure request will be executed by the server, and the application will get a configure notify in confirmation. Finally, the application needs to be prepared for window managers which are either broken, or which chose not to play by these rules -- to deal with those cases, applications need to time out if they don't receive either an acknowledgement or configure notify within some period of time. There are now three ways in which applications can deal with the configure requests they issue: 1. They can issue requests, assume they were denied, and then be pleasantly surprised if a ConfigureNotify informs them that their request was granted. 2. They can issue requests, assume they were granted, and then try to recover previous state when they receive a WM_CONFIGURE_DENIED message, or a ConfigureNotify granting a different request. These applications would either be incorrect if no ConfigureNotify ever arrived, or they might set a timer and recover state if no ConfigureNotify comes within some specified time. 3. They can issue requests and wait for either a ConfigureNotify, a WM_CONFIGURE_DENIED, or a timeout to occur, before taking any further action. If the timeout occurs, they should assume that the configure request was denied. In this case, applications should be careful not to issue configure requests that are no-ops, since the server does not send ConfigureNotify's in response to configure requests that don't change any state. When an application issues a configure request, the x and y it specifies should always be in root, not parent-relative, coordinates. This will work fine when there is no window manager, or when the window manager does not reparent. Reparenting window managers should be prepared for the fact that the request they are getting is in root coordinates (this, in fact, should make life easier on both the window managers, and the clients). There remains a problem having to do with moving windows on the screen under reparenting window managers. Some applications may need to know their screen coordinates so that they can pop up dialog boxes and menus in reasonable places. Since moving a reparented window moves its frame, and thus does not generate a Configure Notify on the application window, the application will not know that its window was moved by the user. Thus, we require reparenting window managers to inform applications that their windows have been moved. They do so by sending a client message to the application window. This message will contain WM_MOVED as the message type. The data contains the window's new outside x and y coordinates (in root coordinates). This proposal is fairly simple. There are a couple of obvious "complications" which may or may not be worth it. For example, should WM_CONFIGURE_DENIED include as data some hints for what the window manager is willing to give instead? (Applications, of course, could not actually count on getting whatever the hints suggested on their next request, because the state of the screen may have changed by then). Comments? Hania Gajewska Mark Manasse Digital Equipment Corporation Palo Alto 2449 11/10 kimbrough%dsg.csc Re: Open Issues Regarding X Properties <<David Rosenthal writes: c. How can an application itself support multiple-levels of zooming? I disagree with this w ------- End of Forwarded Message