Possibly identified the cause of window moving/sizing issues (seems due to animation timing and using move/size independently)

[MarqueIV]

There seems to be an issue with setFrame, the grid-related functions and anything else related to window moving/sizing, and I think I've identified the issue as being related to the new os animations.

Specifically, it seems if you attempt to move/size a window while there's an existing animation, that action gets interrupted with the new call, thus the window isn't moved/sized correctly.

The hack I've come up with to get around this is rather than this....

window.setFrame(targetFrame)

I now do this...

window.setTopLeft({
    x=targetFrame.x,
    y=targetFrame.y
})

os.execute("sleep 0.25") -- Must be long enough to allow the move animation to complete.

window.setSize({
    w=targetFrame.w,
    h=targetFrame.h
})

where 0.25 seconds is usually enough to ensure the move animation happens completely before the resize operation. (You can reverse the order and you'll have the same effect.)

I've also seen cases where moves requiring longer distances equally require a longer time to animate, but the above seems to work for my particular use-case.

I'm somewhat confident this is the issue as when I reduce the delay, say down to 0.1 seconds (any value less than the needed animation), windows don't end up where they're supposed to be. It's also incredibly subtle if you're right at the limit of the animation as it can seem the sizing is only a few pixels off, when in reality, the correct values were set, it was just interrupted right before it was completely animated into place/size.

As I said, I have this workaround, but I'm not crazy about it as now there are essentially two animations that happen when moving/sizing windows, but at least they end up where they're supposed to be.

[MarqueIV]

Bueller? Bueller?

[minusfive]

Do you have an example of the issues you mention? Or perhaps can you share the code you're using? I use hs as my primary/only window manager and don't experience any issues, so curious. Perhaps there's something I can help spot?

[MarqueIV]

Can you try my above code without the delay and see if it moves as you expect? You need to make sure the window moves a long distance or else it will appear to work correctly.

For instance, if you have a 4K screen, place the window off the lower-right of your screen, basically as far from the upper-left corner as you can get it. Then use the move and size calls to move it to the upper left corner, maybe 1/8th the screen width and height. (It's even easier if you have multiple monitors.)

The point is it has to move a long-enough distance to make sure the animations from the first call are not yet completed when the second call starts. That's the issue, and why the pause 'fixes' it.

Lemme know if you can repro it that way.

[MarqueIV]

@minusfive, did you give it a try?

[minusfive]

@MarqueIV, no, sorry, I'm busy. But I did quickly record a video for you of things working fine for me with animation and without delay. I use a 5K screen (5125 x 2160):

Screen.Recording.2025-01-16.at.01.44.49.mov

You can peruse my custom WindowManager spoon here, in case it helps: https://github.com/minusfive/dotfiles/blob/main/.config/hammerspoon/Spoons/WindowManager.spoon/init.lua

Top level I'd suggest trying setFrameInScreenBounds instead of setFrame.

[MarqueIV]

Just watched your video. I can see that working fine because it's not doing the resizing which is what causes the actual problem. Your video looks like it's only doing moves. Can you change it so it's resizing from a quarter to a half or full screen to centered that kind of thing.

I'll also try out your spoon when I'm back in front of my computer.

[minusfive]

It is resizing, I’m just doing it too quickly.

[minusfive]

@MarqueIV here's a new video:

Screen.Recording.2025-01-16.at.10.00.35.mov

[minusfive]

@MarqueIV did that help?