On Tue, May 30, 2006 at 09:34:06PM -0700, Andrew Pimlott wrote:
On Tue, May 30, 2006 at 11:11:11PM +0200, Dominik Vogt wrote:
On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote:
To resolve this issue, we must 1. decide whether the outline should
initially appear snapped or unsnapped;
Unsnapped. In case of moving a window, placing it before touching
the mouse should not move the window at all.
Hmm, I didn't really think about this case. However, I'm not sure that
makes the most sense. Surely if you initiate a move, you want to put
the window someplace other than where it was? And as soon as you move a
single pixel (which most people would do without even meaning to,
assuming they are using the mouse), the window will snap, causing a
jarring discontinuity. I think I would rather have the snap happen
right away.
Anyhow, if we go with your answer, fixing the code is non-trivial. The
whole event loop would probably need to be cleaned up. I don't think
I'm up to doing it myself.
It actually wasn't this bad. The idea behing the test in the
ButtonReleasee handler was to make sure the window is snapped if
the window did not move before, but the pointer position in the
release event moved the window.
In my eyes, the window should not move at all if the pointer does
not move (i.e. the user changes her mind or is just playing with
the mouse, as I often do). == The window should not be snapped
The patch I have just committed makes sure the ButtonRelease
applies the snapped position, even if the pointer did not move.
Initial snapping in your patch was flawed because it ignored the
do_snap flag which was not set at that time (you'd have to query
the X server for it). I removed the initial snapping, but with
in outline mode you sometimes (or maybe always) get initial
snapping because some EnterNotify or LeaveNotify event triggers a
faked motion event. This does not happen in opaque mode.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
