On Sun 02 Dec 2007 at 15:39:38 -0800, Martin Blais wrote:
> Allright, Rhialto, I looked into it, I'm pretty convinced that these
> comments out bits were just for debugging stuff.
> Sorry about that.
Sure, no problem. I've done things like that too.
I've been trying this option, and I like it. I even thought it should
just be made default on.
There is one side effect though from the warping to the window: it gets
moved to the front. Which is probably a good thing in most cases when
you explicitly warp the pointer (I use the warp ring, for instance, and
then it is absolutely essential). But normally I don't like my active
window to move to the front.
I notice that
NoRaiseOnWarp
This variable indicates that windows should not be raised when
the pointer is warped into them with the f.warpto function. If
this option is set, warping to an occluded window may result in
the pointer ending up in the occluding window instead the
desired window (which causes unexpected behavior with
f.warpring).
and indeed, with f.warpring I do want to raise windows. (Note that this
bit of documentation contradicts itself: first it says it only applies
to f.warpto, later it also implies f.warpring. It probably really
applies to all cases of warping, of which there are several more, if you
grep the manual).
Maybe some heuristic can be found when to raise a window when warped to,
and when not.
My first attempt would be to distinguish "explicit" and "implicit"
warps; always raise the destination window on "explicit" warps, and
never on "implicit" ones.
The warps for SaveWorkspaceFocus should be implicit, those for
f.warpring should be explicit; f.warpto and f.warphere should perhaps
obey NoRaiseOnWarp.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
