Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.windows.x Subject: Re: WM_TRANSIENT_FOR hint Message-ID: <1991Apr30.151034.15274@alphalpha.com> Date: 30 Apr 91 15:10:34 GMT References: <1145@tetrauk.UUCP> Organization: asi Lines: 54 In article <1145@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >I would like to know how consistently different window managers treat windows >created with the WM_TRANSIENT_FOR property (i.e. using the I just went through hell trying to get this to work right under OLWM, so... >a. Honours PPosition & PSize hints absolutely I haven't tried setting these explicitly, but setting the the positions of the dialog under Xt does seem to do the right thing. >b. Does not display title bar buttons This is actually configurable under Mwm. For some people they won't show up, for others they will. Note that OLWM doesn't display the title, even if you explicitly set it. >c. Allows the window to be moved and resized, but not zoomed of iconified OLWM does allow it to be moved, but not resized (I actually like that and configure my Mwm the same way). However OLWM doesn't give you much of a handle to move a dialog. I've had customer complaints about that. >d. Hides the window when the parent is iconified Ha. OLWM does not. I currently have all my dialogs watch for Iconify events on their parent and unmap themselves when their parent is iconified - remap when it comes back. I can send you the code upon request. >e. Preserves stacking order - > the window cannot be placed under its logical parent OLWM doesn't do this either. I gave up. Other suprises I got with OLWM (these in click-to-type mode). When you popup a dialog it doesn't get the focus automatically - you have to click. Ditto for de-iconifying a window. >My question is: do all WMs provide this behaviour for transient windows? It >would be much better if I can leave the logic of this to the WM, but can I rely >on it if I don't know what WM the user will be running? The only alternative >would be to support all this within one large application window, but I don't >really want to do that. I wouldn't do it all in one app window. I guess my feeling is that if a user really wants to put up with it then they should be able to. I know some people don't like the fact that dialogs stay on top. It is probably worth noting in your release notes or something however, so they don't come complaining to you. >Is there any standard reference on what a WM should do with these sort of >things, or is it all just "implemetation defined"? Tsk, tsk. X provides mechanisms, not policy :-). -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.