✨ Resizing adjacent windows

[boedy]

Feature Request Description

When using macOS's split-view feature, the ability to adjust the middle divider for dynamic window resizing is quite useful, as demonstrated here:

resize.mov

It would be cool if similar logic can be supported by Loop. Here's what I envision for this feature:

• Dynamic Window Resizing: Adjusting the size of one window should cause adjacent windows to resize accordingly, maintaining its alignment.
• Unified Adjustment for Shared Borders: Windows hidden behind the active window, which share a border with the resized window, should also resize dynamically. This creates a consistent layout and alignment.
• Padding Support: Adjustments should respect user-defined padding settings to maintain the visual consistency and usability of the workspace.

A potential implementation could involve user-adjustable virtual grid lines. Currently, the default possible grid (excluding the "Almost Maximize" setting) looks something like the following if I'm not mistake.

As an example, if a window is snapped to the Top Left Third and the user resizes it downward, all windows within this cell should reflect the change. Moreover, future window snaps would adhere to the adjusted layout. Here's what a 2 x 3 layout adjustment might look:

In terms of how Loop will detect and respond to window resizing actions would still be up for discussion. You could listen to window resizing events from the OS or implement a custom solution making use of preview windows, which might better reflect the impact of the resize on all windows.

I'm keen to hear your thoughts on this proposal and whether it aligns with your vision for Loop's evolution.

Screenshots

No response

Additional Context

No response

Final Checks

• My issue title is descriptive
• This is a single feature request (multiple feature requests should be reported individually)

[mrkai77]

I really like this idea!

I believe that the best option would indeed be to listen to window resize events. It would be a little similar to tiling window managers in the sense that it will automatically "tile" the windows in accordance to your current layout (apps such as Amethyst and Yabai can already do this).

Another option would be to implement Loop's own "resize bar" much like the split screen functionality on MacOS, where it's already linked to the two windows it's beside, and all the user would need to do is drag on that slider.

However, I am still focusing on the bugs/feature requests that are more related to Loop's "core" functionality so I wouldn't expect this to be in Loop for at least a couple more releases :)

[boedy]

It would be a little similar to tiling window managers in the sense that it will automatically "tile" the windows in accordance to your current layout (apps such as Amethyst and Yabai can already do this).

Exactly! However, traditional tiling window managers (like Amethyst and Yabai) often adopt an all-or-nothing strategy, presenting a challenge each time a new window opens. Users are compelled to immediately address this by choosing to float, stack, or reposition the window. From my experience with these managers, I found that the effort spent on constant window adjustments hindered my productivity, rather than enhancing it, especially compared to simpler window management solutions.

Moreover, there are moments when a single terminal window occupies the entire screen on an ultra-wide monitor, which is unnecessarily large and impractical.

The solution I'm proposing aims to refine this interaction by only resizing windows that share an edge, providing a more intuitive and natural window management experience. I'm in the process of developing a proof of concept for personal use, leveraging Hammerspoon. This feature, which I've been referring to as having sticky or magnetic edges, allows for a window to 'detach' or 'unstick' from its neighbors when moved.

Another option would be to implement Loop's own "resize bar" much like the split screen functionality on MacOS, where it's already linked to the two windows it's beside, and all the user would need to do is drag on that slider.

I think this approach would definitly make more sense when padding is used. It would also allow for the rendering of preview windows, potentially offering a more performance-efficient solution than resizing multiple windows in real-time.

[JaceThings]

When I first read this ticket, I thought "isn't this just like any other tiling window manager which Loop is not trying to be?" But then I read how you were talking about how, with Amethyst, it is kind of like all or nothing, but your idea is actually just to take the best parts and put them within Loop, so I'm no longer against this idea anymore, and if anything, I would actually love this idea if it were a toggle.

[boedy]

I agree that this feature would be best introduced as an optional toggle, rather than being active by default as it's probably more of power-user feature

Over the past two days, I've dedicated some time to develop a proof of concept using Hammerspoon. Although the code is somewhat buggy, I've created a screen recording that effectively demonstrates the envisioned functionality:

Screenshot.2024-03-27.at.18.46.28-converted.mp4

[JaceThings]

Damn, is it not possible to resize the window before the user lets go of the mouse? Having it snap to the size on mouse release is kinda.... eh

[davidjyliu]

Accidentally created #348 as a duplicate of this feature request, but since I already wrote a whole blurb and had screenshots, I'll add them here and see if they can service as... inspiration? Hope this feature gets implemented soon and I can make the move to Loop for good.

Additional Info:
To my knowledge, this features exists in Swish and Rectangle Pro. Swish resizes the adjacent window "in real time" as the user drags the border, while Rectangle Pro only resizes the adjacent window once the user releases the mouse button. Swish's method is visually smoother, while Rectangle Pro's approach can be visually jarring. Is there a way for Loop to achieve an effect similar to Swish's resize adjacent window feature?

Screenshots

[mrkai77]

@davidjyliu yes, I do plan on making it smooth rather than computing the resize after the window's resize :)
I will try experimenting with this functionality!

[solid-pixel]

forgive me for being dumb, but has this been implemented?
I'm confused because the README says Loop can do this, but it doesn't seem to be the case and I find no settings to enable that.

Currently using v1.3, but it was the same on the latest Stable.

Either way, impressive app, thank you so much :)

CleanShotX.-.Windsurf.28.03.2025.at.13-31-31.mp4

Settings

[JaceThings]

This is because you are dragging from the area that forcefully exists so that the user can drag the window without moving adjacent windows.

You must drag from the indicator for this to function.

005156.mp4

[solid-pixel]

ohhh I missed that, it does indeed work, thank you!

It might be worth documenting the fact that this only works when "Use macos window manager when available" is toggled on. But otherwise it works perfectly, thanks 🎉

[tddouglas]

Agreed! That was what I was missing as well. This is really sweet. Been looking for this in my Mac since switching over from Windows!

Does it work for tiling beyond just a left/right split?
The resize bar shows up when I have 2 windows adjacent to one another like this:

However, as soon as I add additional windows, I can no longer view the resize bar:

[mrkai77]

At the moment, no, the system window manager does not support anything beyond the system's own implementation. However, I have also been (although slowly) been working on a backup adjacent window manipulation solution as well :)