I'm a bit curious as to whether anyone is relying on the following
quirk of sawfish:
* a window is matched
* a window is sent to a specific viewpoint
that the following behavior occurs
* the current viewport is set to that viewport
I can't think of a specific reason why this behavior would be
desireable, but it's possible that someone is relying on it.
I open a large number of windows ("setting up the environment")
automatically at sawfish launch, and dislike having sawfish zip around
following the current viewport. I'd really like to just have the
windows open offscreen, killing line 361 in match-window.jl, and not
modifying the current viewport.
I've also considered adding another boolean option
"do-not-switch-to-viewport", but that seemed a bit over-complicated if
nobody is using such a function. Also, my understanding is that
adding a new window setter of the sort might not work:
(define-match-window-setter 'viewport
(lambda (w prop value)
(declare (unused prop))
(unless (window-get w 'placed)
(unless (window-get w 'do-not-switch-to-viewport)
(set-viewport w (1- (car value)) (1- (cdr value))))
(set-window-viewport w (1- (car value)) (1- (cdr value))))))
The reason why is that, as far as I can tell, match window setters
aren't expected to interact with each other, which means that the
window properties resulting from a match might get set in any order,
and the setters called before all the properties are set. Which means
that at the time this function is being called, the
"do-not-switch-to-viewport" property might not exist. Am I wrong on
this point?
--
Best of luck,
Mark Schreiber
Attachment:
pgpI9WdKEDK4J.pgp
Description: PGP signature