Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!cadillac.siemens.COM!ellis From: ellis@cadillac.siemens.COM (Ellis Cohen) Newsgroups: comp.windows.x Subject: Re: window manager property semantics Message-ID: <8710121519.AA08693@audi.siemens.com> Date: Mon, 12-Oct-87 11:19:55 EDT Article-I.D.: audi.8710121519.AA08693 Posted: Mon Oct 12 11:19:55 1987 Date-Received: Tue, 13-Oct-87 06:07:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 77 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.