The way raise-lower-window acts has been bothering me lately.  I have
transients-above set to none and user-raise-type set to group.  If the
two topmost windows are in the same group and I click on the second
window the entire group is lowered.  This feels wrong because the
second window could be raised.

The function responsible for this is raise-lower-windows in
sawfish.wm.stacking.  It seems rather complicated.  Am I missing
something if I suggest the following simpler implementation, which
would seem to correct the problem I was experiencing?

  (define (raise-lower-windows w order)
    (if (or (eq (window-visibility w) 'unobscured)
	    (window-on-top-p w))
	(lower-windows w order)
      (raise-windows w order)))

I also have doubts about the behaviour of user-raise-type transients,
which in addition to affecting immediate and higher order transients
of the target window also affects windows the target is transient for.
The inclusion of the parent windows seems unnatural.  Siblings of the
target are not affected.

It might also be useful to have commands for raising and lowering
groups without affecting the stacking order within the group.

Is there a way to replace at run time the definition of a single
function in a module without reloading the entire module?  It would
be useful for testing.

	Timo Korvola		<URL:http://www.iki.fi/tkorvola>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]