Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!converse From: converse@EXPO.LCS.MIT.EDU (Donna Converse) Newsgroups: comp.windows.x Subject: Re: TransientShell widget. Message-ID: <8907312052.AA27435@expo.lcs.mit.edu> Date: 31 Jul 89 20:52:49 GMT References: Sender: daemon@bloom-beacon.MIT.EDU Organization: X Consortium, MIT Laboratory for Computer Science Lines: 38 > I am having trouble with transient shell widgets. I am able to iconify them > separtely even when the parent is not iconified. I am creating and mapping > the pop up widget as follows: [code deleted] > > XtPopup(popup,XtCallbackNone); The second argument to XtPopup is of type XtGrabKind; XtCallbackNone is not of type XtGrabKind. > A note in the ICCCM manual (page 32) says: > > "Window managers are free to decide if WM_TRANSIENT_FOR windows should be > iconified when the window they are transient for is. Clients displaying > WM_TRANSIENT_FOR windows which have the window they are transient for > iconified do not need to request that the same operation be performed on > the WM_TRANSIENT_FOR window; the window manager will change its state if > that is the policy it wishes to enforce" > Shell widgets of class transientShellWidgetClass have the WM_TRANSIENT_FOR property set. They are transient for (on behalf of) some other window. The passage above discusses the issue of iconifying the transient when the window it is transient for is iconified. You are asking about it the other way around. Separately iconifying a transient window is not prohibited by the ICCCM. Whether it is allowed is an issue of window manager policy, implying that the application can't prevent the transient from being separately iconifed. So... what you see is not a problem. It might allow the user to get some useful work done. If it's deadly to your application, use an override shell and grab the pointer while the override shell is mapped. Donna Converse converse@expo.lcs.mit.edu