dfc@Inference.COM (Deborah Catalano) (02/01/91)
From: jimg@apollo.com (hit "D" now)
Date: Thu, 31 Jan 91 11:25:44 EST
Sender: jimg@apollo.com
There ought to be an answer to this, but I haven't found it.
I have a client application that wants to notice when it is
obscured by other windows and, under certain circumstances,
wants to be raised to the top of the window stack. I can add
an event handler to the toplevel shell widget and have it
Map and Unmap itself, but making the window blink out and flash
on again is ugly and messy.
What I'd really like to do is just send a request to the window
manager and ask it to raise my window to the top. I'm running
mwm.
Is there a way to do that?
Yes, we had to do something similar. Use XConfigureWindow (if using
X11R3) or XReconfigureWMWindow (if using X11R4). Note: you have to
use the parent of the dialog box if using the Motif Dialog convenience
routines (e.g., XmCreateFormDialog).
Here's the code that works for me:
/* Declarations....*/
XWindowChanges *winchgs = (XWindowChanges *)malloc(sizeof(XWindowChanges));
unsigned int value_mask;
/* other code .... */
. . .
winchgs->stack_mode = Above;
value_mask = CWStackMode;
#if X11R4
XReconfigureWMWindow(display, XtWindow(XtParent(dialog_widget)), screen_num, value_mask, winchgs);
#else
XConfigureWindow(display, XtWindow(XtParent(dialog_widget)), value_mask, winchgs);
#endif
/* end of code sample */
Good luck!
-----------------------------------------------------------------------------
Debbie Catalano catalano@inference.com
Inference Corporation 213-322-5004 x194
550 N. Continental Blvd. Fax: 213-322-3242
El Segundo, CA 90245
-----------------------------------------------------------------------------nazgul@alfalfa.com (Kee Hinckley) (02/02/91)
> > You should read ICCCM and learn why client programs should NOT attempt to > control (top-level) window stacking order. > > The rationale: All rights to top-level window configuration belong to the User > King and should not be usurped by pesky clients. The tool through which the User > King exerts these rights is the window manager. For all rules there are exceptions. The reason we do a raise is that the user has just asked for a compose window so they can send mail. We cache the compose window and remap it on request. At least one WM keeps the stacking order the way it was before the window was unmapped - which may place it behind existing windows. The user's intent was clearly to place it on top, so we do. On most WMs though the request is a noop, since it's already there. In general though, I agree, and in fact the code I sent won't work if the widget has been reparented - which is fine, since the only case we care about is a non-reparenting window manager :-).