Option to re-enable old behavior of "warp" keyword
Closed this issue · 5 comments
Describe the new feature
Issue #551 changed the be behavior of the warp keyword to move the mouse to the middle of the window. My workflow was heavily dependent on the old behavior, where the mouse stayed in the same position relative to the moving window.
I would like to request that the old behavior be restored. Recognizing that issue #551 has it's own use case, my preference would be that the issue #551 behavior be enabled by a new keyword like "warptocenter" or similar. If retaining the current behavior as "warp" is desired, the old behavior could perhaps be assigned a new keyword like "warprelative"
- What is it which fvwm3 doesn't do at the moment, but should?
Behavior of "warp" keyword changed, I would like to re-enable the old behavior.
How might fvwm3 need to change?
- Non-technical thoughts about the impact this will have in
fvwm3, what
might need to change, and whether this impacts backwards-compatability.
issue #551 broke backward compatibility, I'd like to re-enable that compatibility. May require new keyword assigned to allow for both old and new behavior as distinct use cases.
Can this be achieved through scripting?
not as far as I know.
- Is a proof-of-concept available externally through scripting
fvwm3?
not that I know of.
- Does this functionality exist elsewhere in other WMs, if so, which?
fvwm2
Hi @mnejedlo
I wouldn't say it broke backwards compatibility -- it fixed what I consider to be a bug.
I really don't want an option to make the now changed behaviour its own option.
Why do you want the old behaviour? You can still achieve it by passing parameters to the Warp command.
I've a mind to close this issue as a result.
I agree, the original issue was the behavior was not working as documented. With the old behavior it could happen that the pointer isn't even warped to the window. The warp option with the Move command is there to ensure the mouse is in the window (center is a good location) after the window is moved.
If you want more control of where the mouse moves, instead of using Warp option of the move command write a custom function and use WarpToWindow. It may take a little computation in a shell, but you could write your own function that would save a windows current location, move it, then use WarpToWindow to move the mouse relative to where you want it (though it may require a bit of computation if you want the mouse to appear outside of the window).
So, here's my use case. In fvwm2, I have:
Mouse 1 7 A Move 0 keep Warp
Mouse 3 7 A Move -0 keep Warp
Mouse 4 7 A Move keep 0 Warp
Mouse 5 7 A Move keep -0 Warp
Depending which mouse button I click on title bar button 7, I can move the window to the left/right/top/bottom. In fvwm2, if I want to move a window to the top-left corner, I can click mouse button 1, then immediately mouse button 4 because warp keeps my mouse over title bar button 7. In fvwm3, I click button 1, then have to move my mouse back to button 7 before I can use button 4 to move the window to the top of screen.
I've not put time into reproducing the issue #511 use case, but at least the way I use it I've never had the mouse pointer end up anywhere other than staying over title bar button 7 when move/warping.
If there's another way to achieve this behavior, I'd love to know about it. I didn't see anything parameter like for Warp in the 1.0.4 man page I have on my machine (yes, I know it's old), and I'm having dead link problems with browsing the docs on github, so I can't check if there's something that was added since 1.0.4.
I think you are missing the WarpToWindow command mentioned above. I also think you are using the assumption that the mouse is over the window before it moves. Fvwm can move windows based on key bindings, events, and so forth, which can lead to moving windows the mouse is not over. In the case the mouse is not over the window before the move, it won't be over the menu after the move (before the issue was fixed), in which case even though the mouse was moved, it was not warped to the window, hence the bug.
Instead you should think of there being two different actions, first the Move and after that action is complete, WarpToWindow moves the mouse. If you wanted you could write your own function. For instance what the Warp option is actually the following two commands (Mouse 1 7 A MoveTop will do the exact same thing as your current binding):
DestroyFunc MoveTop
AddToFunc MoveTop
+ I Move 0 keep
+ I WarpToWindow 50 50
I think it is reasonable that the default position to warp the pointer to is the center, but I undersatnd not everyone will think that is the best place for the mouse to be warped to. In that case you should use your own function and not the Warp option of the move command. In your case you would write a custom function to use such as:
DestroyFunction MoveAndWarp
AddToFunc MoveAndWarp
+ I Move $0 $1
+ I WarpToWindow 100p 15p
Mouse 1 7 A MoveAndWarp 0 keep
Mouse 3 7 A MoveAndWarp -0 keep
Mouse 4 7 A MoveAndWarp keep 0
Mouse 5 7 A MoveAndWarp keep -0
The function takes the parameters $0 and $1 so we don't have to write four different functions, and you'll have to adust the location in pixels you want the mouse 100p 15p to fit the location of button 7. Now the advantage of this is now you can call this function even if your mouse is not over button 7 and it will always be over button 7 no matter where the mouse started.
If you really wanted to recreate the old behavior, you would need to write a tiny script using the starting location of the window, [$w.x], [$w.y], and the pointer [$pointer.x] and [$pointer.y] to compute the location inside the window to warp to, then call WarpToWindow with that computation.