mikeo@sae.UUCP (Michael Ovington) (04/10/90)
We have an application that can, at the user's request, generate multiple top level windows (with XtCreatePopupShell). If the user doesn't delete these windows, older windows can become obscured by newly created ones. When the user asks the application to display a window that is already created, but obscured, I would like to be able to just raise it rather than recreate it. If the application is running under a reparenting window manager, I obviously can't raise the window of the Shell widget I created. Is it OK to walk up the window's parents until I get to the root window, and raise child of root that I find? I don't see this situation covered in the ICCCM. If it is, could someone please quote me chapter and verse. If my workaround shouldn't be used, could someone suggest a portable way for communicating the raise request to the window manager? ________________________________________________________________________ Michael S. Ovington Software Architecture & Engineering (703) 276-7910 1600 Wilson Blvd, Suite 500 uunet!sae!mikeo Arlington, VA 22209 mikeo@sae.com ________________________________________________________________________
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (04/11/90)
> We have an application that can, at the user's request, generate > multiple top level windows (with XtCreatePopupShell). > When the user asks the application to display a window that is > already created, but obscured, I would like to be able to just raise > it rather than recreate it. > If the application is running under a reparenting window manager, I > obviously can't raise the window of the Shell widget I created. But you can, sort of. From the ICCCM, section 4.1.5: Clients changing their position in the stack must be aware that they may have been reparented, which means that win- dows that used to be siblings no longer are. Using a non- sibling as the sibling parameter on a ConfigureWindow request will cause an error. Convention: Clients using ConfigureWindow to request a change in their position in the stack should do so using None in the sibling field. Clients that must position themselves in the stack relative to some window that was originally a sibling must do the ConfigureWindow request (in case they are running under a non-reparenting window manager), be prepared to deal with a resulting error, and then follow with a synthetic Confi- gureRequest event by invoking SendEvent with: destination: the root propagate: False event-mask: (SubstructureRedirect|SubstructureNotify) event: a ConfigureRequest with: event: the root window: the window itself .... other parameters from the ConfigureWindow Doing this is deprecated, and window managers are in any case free to position windows in the stack as they see fit. Clients should ignore the ``above'' field of both real and synthetic ConfigureNotify events that they receive on their non-override-redirect top-level windows since they cannot be guaranteed to contain useful information. There's an Xlib routine to do exactly this. From the Xlib doc, section 9.1.1: To request that a top-level window be reconfigured, use XReconfigureWMWindow. Status XReconfigureWMWindow(display, w, screen_number, value_mask, values) Display *display; Window w; int screen_number; unsigned int value_mask; XWindowChanges *values; [argument descriptions cut to save space] The XReconfigureWMWindow function issues a ConfigureWindow request on the specified top-level window. If the stacking mode is changed and the request fails with a BadMatch error, the error event is trapped and a synthetic ConfigureRe- questEvent containing the same configuration parameters is sent to the root of the specified window. Window managers may elect to receive this event and treat it as a request to reconfigure the indicated window. > Is it OK to walk up the window's parents until I get to the root > window, and raise child of root that I find? Probably not. I really think, if all your created windows will be the same size and position (which can't be guaranteed anyway), you'd be better off creating one top-level window and the making all your "real" windows children of it. Then you can restack them freely and the window manager won't even notice. Note that the window manager is free to ignore or override your attempts to restack the windows, as the ICCCM points out. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
smarks@eng.sun.COM (Stuart W. Marks) (04/11/90)
| When the user asks the application to display a window that is already | created, but obscured, I would like to be able to just raise it rather | than recreate it. | | If the application is running under a reparenting window manager, I | obviously can't raise the window of the Shell widget I created. Is it | OK to walk up the window's parents until I get to the root window, and | raise child of root that I find? Actually, you do simply raise the Shell widget. (But I agree that it isn't obvious.) This works because a reparenting window manager will have selected for SubstructureRedirect on its parent window, so the request to raise the window will get redirected to the window manager. Thus, issuing an XRaiseWindow call (or whatever) on the Shell widget is always the right thing to do. Now, it's not guaranteed that the window manager will honor your application's request to raise the window to the top. Some window managers will decide that they don't want to honor stacking order requests, and so your application will have to live with that. Please don't walk around the window hierarchy and manipulate windows that you think are the right ones. There's a possibility that the direct child of root that you find isn't the window manager's parent window, but is a pseudo-root window of some sort. Raising this window is NOT what you want to do! | I don't see this situation covered in the ICCCM. If it is, could someone | please quote me chapter and verse. There's a discussion of stacking order requests towards the end of section 4.1.5 of the ICCCM. | If my workaround shouldn't be used, | could someone suggest a portable way for communicating the raise request | to the window manager? Using XRaiseWindow (or other configuration requests) directly on the Shell is the most portable way. It's certainly more portable than searching the window tree. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Window Systems Group UUCP: sun!smarks Sun Microsystems, Inc.
news@src.dec.com (News) (04/12/90)
Raising the shell window should, in fact, work IF the window manager allows it to. Since most reparenting window managers select for SubstructureRedirect on the parent of top-level windows, your stacking request will be sent to the window manager, which will then act on it as it sees fit. This doesn't mean that your window will be raised, just that the window manager gets a chance to decide if it should be. The ICCCM recommends that you not set a sibling; if you do, you'll need to be prepared to handle the X error that may result if the window is reparented under a non-redirecting window manager. Mark
stripes@eng.umd.edu (Joshua Osborne) (04/12/90)
In article <9004092038.AA07859@sae.com> mikeo@sae.UUCP (Michael Ovington) writes: > We have an application that can, at the user's request, generate multiple > top level windows (with XtCreatePopupShell). If the user doesn't delete > these windows, older windows can become obscured by newly created ones. [...] > I don't see this situation covered in the ICCCM. If it is, could someone > please quote me chapter and verse. If my workaround shouldn't be used, > could someone suggest a portable way for communicating the raise request > to the window manager? Have you tried withdrawing the window, then un-withdrawing it (what is the un-withdrawed state called? Normal?). That's legal ICCCM, not that a window manager will be able to (easily) figure out that this is a restacking request it should work most of the time.... (if you find a ICCCM restack use it, forget I said this, etc.) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert