On Wed, Oct 27, 2004 at 09:07:55PM +0000, Mikhael Goikhman wrote: > On 27 Oct 2004 11:59:57 -0700, [EMAIL PROTECTED] wrote: > > > > > The intended logic is simple, as long as Alt is pressed, there is no > > > snap-attraction; as long as it is not pressed, there is one. > > > > > > It is possible to press and release Alt as many times as needed to switch > > > snap-attraction on and off while moving windows using keyboard or mouse. > > > > Not when alt being continuously pressed is part of your only way of moving > > a window...which is the workflow I put SnapAttraction into fvwm in the > > first place for. Therefore, I hope that this new intended logic is not > > really intended anymore. > > > > Really, this toggable snap feature thing should be via some bindable event, > > not a specific modifier (like an alt key), and it should be unbound (off) > > by default. > > It was on in 2.5.10, and it seems you liked it. The toggle-able snap > feature worked starting with the first fresh Alt press. > > There are many hardcoded bindings, like Ctrl-arrows moves a window by 1 > pixel in interactive Move. Middle mouse button cancels Move, third button > activates a certain window flag. This is good. Noone complained yet. > > In short, I agree that the logic from 2.5.10 should be restored. but I > think your suggestions are redundant.
I see where the problem is. Traditionally, we never bothered to set the modifier states on faked motion and keyboard events. This erases the initial Alt state since one of my recent patches. Fixed with my next commit. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
pgpKWVGOo9pF2.pgp
Description: PGP signature
