On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote: > I have been bothered by a situation where I create a window and manually > place it at one location, but the window actually appears in a different > location. It is easy to reproduce with a very small .fvwm2rc: > > Style * ManualPlacement > EdgeResistance 0 100 > > Start by placing an xterm in the lower right corner of the screen, > touching the side and bottom. Place the mouse near the upper left > corner of the window, within the window. Type "xterm" and press enter. > You will see the new window outline appear exactly over the border of > the first xterm; that is, it appears snapped to the edges of the screen. > Press enter to place the window. Note that it is placed not where the > outline was, but at the pointer position. > > I investigated the code in __move_loop, in move_resize.c. (I am using > fvwm 2.5.16, but the file is identical in the 20060529 snapshot I just > checked). The problem is that in "case ButtonRelease" (line 2445), > there is a test that says if the mouse is in the same position it > started in, don't apply the snap. This idea is that if the mouse didn't > move, the outline never snapped, so the window shouldn't snap either. > This is an ill-conceived test for two reasons. One, the mouse could > have moved and moved back to its original position! It's not actually > that hard to achieve this. Two, there are cases other than mouse > movement that causes the window outline to snap. For example, if an > EnterNotify or LeaveNotify event is received (2301), a MotionNotify > event is faked up, and in "case MotionNotify" (2483), DoSnapAttract is > called to snap the outline. This is in fact what happens in the test > case above. > > However, it is not always the case that the initial outline is snapped. > If there were not already a window below the mouse when I ran xterm, no > EnterNotify event would have been received, and thus the outline would > have appeared unsnapped, at the pointer. This inconsistency is cause of > further confusion to the user: Why does the outline initially appear > snapped sometimes and not other times? > > 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.
> 2. ensure that the outline in
> fact initially appears snapped or unsnapped consistently;
Ok.
> 3. ensure that
> the window gets placed where the outline appeared.
Ok.
> I took what seems to be the simplest approach (a necessity for me, given
> the serpentine nature of this function), which is also the behavior I
> find the most natural: I decided that the outline should always start
> out snapped. It is only a couple of lines to snap the outline at the
> top of the function, and then unconditionally snap on ButtonRelease.
> The below patch Works For Me.
>
> Andrew
>
> PS. Please Cc: me, as I am not subscribed.
>
> --- move_resize.c.orig 2006-05-29 14:15:16.000000000 -0700
> +++ move_resize.c 2006-05-29 14:18:37.000000000 -0700
> @@ -2197,6 +2197,10 @@
> xl_orig = xl;
> yt_orig = yt;
>
> + /* Without this, the outline sometimes initially shows snapped,
> + * sometimes unsnapped. At least this is consistent. */
> + DoSnapAttract(fw, Width, Height, &xl, &yt);
> +
> /* draw initial outline */
> if (!IS_ICONIFIED(fw) &&
> ((!do_move_opaque && !Scr.gs.do_emulate_mwm) || !IS_MAPPED(fw)))
> @@ -2463,15 +2467,9 @@
> xl = xl2;
> yt = yt2;
> }
> - if (xl != xl_orig || yt != yt_orig || vx != Scr.Vx ||
> - vy != Scr.Vy)
> + if (do_snap)
> {
> - /* only snap if the window actually moved! */
> - if (do_snap)
> - {
> - DoSnapAttract(
> - fw, Width, Height, &xl, &yt);
> - }
> + DoSnapAttract(fw, Width, Height, &xl, &yt);
> }
>
> *FinalX = xl;
>
>
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
