rick@tetrauk.UUCP (Rick Jones) (04/29/91)
I would like to know how consistently different window managers treat windows created with the WM_TRANSIENT_FOR property (i.e. using the XSetTransientForHint() function). I am currently using the Motif WM, and the behaviour of these windows is exactly right for the application I am building. It does the following: a. Honours PPosition & PSize hints absolutely b. Does not display title bar buttons c. Allows the window to be moved and resized, but not zoomed of iconified d. Hides the window when the parent is iconified e. Preserves stacking order - the window cannot be placed under its logical parent The stacking behaviour is preserved to multiple levels, so a transient window can have transient sub-windows, etc. All are hidden when the overall non-transient parent is iconified. This allows the application to present the visual metaphor of a pile of forms on the desk, but with a constrained logical relationship between them so that the user cannot shuffle them into an incoherent muddle (this is important to the concept of the application I am building). 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. Is there any standard reference on what a WM should do with these sort of things, or is it all just "implemetation defined"? -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Any fool can provide a solution - the problem is to understand the problem
nazgul@alphalpha.com (Kee Hinckley) (04/30/91)
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.