Loop
Loop copied to clipboard
MrKai77
✨ Resizing adjacent windows
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:
https://github.com/MrKai77/Loop/assets/2030968/a6a5d008-5c15-40fb-b0a9-98289d43caa2
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
- [X] My issue title is descriptive
- [X] This is a single feature request (multiple feature requests should be reported individually)
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 :)
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.
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.
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:
https://github.com/MrKai77/Loop/assets/2030968/ab5ddfe5-e567-4a42-baa6-7a9229a88152
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
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
@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!