Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  ICCCM question about raising windows
Message-ID: <9004102110.AA19025@Larry.McRCIM.McGill.EDU>
Date: 10 Apr 90 21:10:43 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 86

> 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