Window stacking / raising design

[Bill Spitzak]

Pekka Paalanem thought this text that I sent was a better description of 
design goals for window stacking:

* Client must make the final decision about raising. This is a 
requirement so that drag & drop can be implemented, as dragging an 
object must not raise the window it is in, and only the client knows if 
the mouse-down is on a object to be dragged. (I am well aware that this 
will allow some GUI behavior that there are people who are vehemently 
opposed to. They will have to convince programmers using merits of their 
arguments rather than force.)

* I consider it imperative that no pixel on the screen changes more than 
one time when it is updated in response to a single action by the user, 
such as activating a window. If activating + raising causes a dialog box 
to appear, the area occupied by that dialog box must change from the 
previous overlaid windows directly to the dialog box, it must not 
temporarily contain the raised main window. (a user action can add, 
remove, reorder, resize, and redraw surfaces, all at once!).