RamonUnch
Expanding on the StickyResize feature
I've been exploring the settings for about an hour now and I'm very impressed! I've found almost everything I've wanted already implemented!! But there is one thing that I don't think has been implemented yet. I looked and I don't see any other issues talking about this. Hopefully I'm able to explain it in a way that you can understand.
I'd like to have an option to extend sticky resize to also affect all windows that are snapped on the same axis as the window currently being resized. Currently sticky resize only resizes windows that are directly touching the resized window, and only changes one axis. What I would like is when resizing the edge of a window, have a line that goes out to the end of that monitor and any window edge along that line gets resized along that edge too, even if that window edge is not touching the currently resized window. Let's take this example below:
If I resize the HumbleBundle window by the top left corner, currently that only moves the right edge of github, and the bottom edge of youtube. I would like it to change both axis of github youtube and twitch, and the bottom edge of discord. Because the bottom edges of discord/twitch/youtube all share the same Y position as the top edge of the window I'm dragging. And because the right/left edge of youtube/twitch respectively share the X position of the left edge of the window I'm dragging.
There is an edge case I can think of, but I'm not quite sure how to concisely describe how the conditions of how to handle it, but I'll try. In this example above, Resizing only the left edge of humble (as opposed to the top left corner), should not resize youtube or twitch, even though they share an edge on the Y axis, because the other edge (in this case the top edge) perfectly aligns with both windows and allows for humble/github to slide cleanly under the top row. However, if the humble window was slightly taller as in this second example below, then resizing humble by only the left edge would resize the left/right edge of twitch/youtube, because the top edges do not perfectly align.
Doing this would allow resizing of multiple windows easily while maintaining the current layout of windows, and minimizing dead space created between windows by sticky resize in its current implementation. Ideally this would have an option to be the default or be on a second modifier key, like shift/ctrl with snap layouts and stretching across multiple tiles.
try with this version of AltSnap.exe + hooks.dll (replace old ones) add to the config:
in the [General] section of the .ini file
StickyResizeMode=1
; Set to 1 to consider all aligned window edges for the sticky resize mode.
; Useful for tiled mode. Default is 0 to consider only directly touching windows.
Tell me if it works for you.
Yes! This is most of the functionality I was talking about. Wow very impressed with the quick turnaround! This does not cover the edge case of (in the first example screenshot) resizing humble by the left edge only (not the corner) not attaching to the top row.
But as long as I can have a modifier key to revert back to default sticky resize that's fine! For example, hold shift to enable sticky resize, holt shift+ctrl to enable edge sticky resize. Ideally I would like to invert that, edge sticky by default, hold shift for normal sticky resize, and hold shift+ctrl for non stick.
here is Ctrl toggle version Shift+Ctrl+Resize was not overloaded before. if you set StickyResizeMode=0 ctrl will enable it and otherwise it will disable it.
I am not sure about the edge case you mention, it is a bit confusing because the edges alighn and are touching, hard to find reliable heuristic. If you want to have a better tiling window manager, you can use dedicated software such as glaseWM or Komorebi.
With the hotkey to manually control it, this is totally workable! Thank you so much. I will make one more attempt at explain the edge case. If it's not workable I understand.
A clean heuristic to check would be to check what window edges are touching the window edge(s) we are resizing. and then recursively check those edges too. I think this would be very similar to your initial implementation, just recursively checks. This implementation would behave slightly differently than my initial idea. but I think it would be both easier to implement and better to use. Since it would have different behavior maybe this would be StickyResizeMode=2, or it could completely replace StickyResizeMode=1. Here's a video to try to explain better.
https://github.com/user-attachments/assets/c28a680c-947b-4696-9cbc-b0b0f853b469
So what is the difference with the current behavior? I tried to reproduce your example and here is what should happens when resizing without shift, then with shift then with Ctrl+shift https://github.com/user-attachments/assets/a24bafae-9120-4dc0-ad76-8dfb3f7864ff
Thanks for taking the time to explain in such details with a video. I will rewatch this later.
Here's another video where I try to go into a little more depth to explain the recursive mode. It sounds a little complicated when I explain it, but I think the actual implementation should be relatively simple. As I think it would be the original implementation, just recursively called on every edge that gets resized. https://github.com/user-attachments/assets/80e9396b-fc4c-43e3-9d68-0f6aae83ddec
If done this way, you could also implement the recursion in such a way that it doesn't trigger if the minimum size is reached, only if the size of the window is actually changing. I'm not sure how you have it coded atm, that may or may not need extra checks, or it may act like that already. Though this would be very low priority in my mind, imo the user should never be doing that anyway. but it would be nice to have it handled anyway.
Thanks again for being so responsive and helpful! Really appreciate it.
I see the problem, I am not sure it is a simple recursion however, the old mode only moves windows that have opposing touching borders. It also ignores the corner from which you resize, it just separate horizontal and vertical movements.
So if you move up left the corner even if the windows were to recursively try to move the edge of their friend they would have to work on a window with a matching border and not an opposing ones.
But I see, I will think about that and come back later with something better, I agree it is a bit too locked.
I'm not sure I fully understand, but I don't have to. I'll just trust you that my recursion idea wouldn't work as I expect. Hopefully there's another way to do it, or at least something similar. For now manually switching between modes with the modifier keys does allow me to do what I want. Even if it's slightly more manual than I'd like. You're a huge help.