mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Feature request: Focus on monitor if there are no more apps left to focus #85
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jrmallorca on GitHub (May 23, 2022).
Originally assigned to: @LGUG2Z on GitHub.
Hello, I just wanna say thanks to creating your twm. Makes dealing with Windows a bit better.
I was wondering whether it's currently possible or not to be able to focus on a monitor if there are no more apps in the specified direction but there is a monitor.
For example, say we had 2 monitors M1 and M2 that are next to each other. M1 is on the left and M2 is on the right. Then say we had two apps A1 and A2. A1 is in M1 and A2 is in M2.
If A1 is currently focused, then when I try to focus right I would like to focus on A2 which is in M2.
@snide commented on GitHub (Jun 14, 2022):
Coming from Linux tiling window managers this was something I immediately missed as well. Similarly, you'd expect the
movecommand in komorebi to do something similar. If the focused application was on the right edge of a monitor, and youmove rightit would move that window to the monitor on the right if one existed.Also echo that this application is FABULOUS. As a designer I don't have much to offer but documentation help on this project, but I'll try and help where I can.
@LGUG2Z commented on GitHub (Jun 15, 2022):
The main underlying issue that needs to be resolved in order to implement this is being able to look at all of the monitors stored in the window manager state (they are indexed according to the numbers given to them by Windows ^), and be able to tell which monitor (if any) is placed to the left, right, top or bottom of the currently focused monitor.
Then, with a reliable way to determine the index of a target monitor, if the user's focus is on a window at the given edge of the current monitor, and there is a physical monitor at that edge, it should be fairly easy to call the existing handlers that exist to operate across monitor boundaries.
Just thinking about it makes my head hurt. 😅
I'll keep thinking about this and playing around with a few different ideas to see how this can work.
@LGUG2Z commented on GitHub (Jun 21, 2022):
@jrmallorca @snide The latest commit on this branch has something that is ready for user testing: https://github.com/LGUG2Z/komorebi/tree/feature/operate-across-monitors
I was only able to test this with one monitor in each direction with my iPad hooked up via Duet; I'd be interested it see if what I've done holds up when there are 3+ monitors in the mix.
@snide commented on GitHub (Jun 21, 2022):
I'll give this a shot tomorrow, ty! I should also have a video done by the end of the week. I'm still learning some of the deeper features and want to make sure I wire up the custom layout template logic.
@LGUG2Z commented on GitHub (Jun 21, 2022):
After doing some more research on how other tiling window managers handle focusing and moving across monitor boundaries, I'm going to modify the
focuschanges across monitors to revert to the last focused tile on the target monitor, and alsomodifythemovechanges across monitors to act as a "swap" operation instead of the current "send" operation which removes the focused window container from the origin monitor and inserts it into the target monitor without sending anything back to the origin monitor.@LGUG2Z commented on GitHub (Jun 21, 2022):
Changing a
moveinto aswapis a lot more difficult than I thought. 😅Putting it on the backburner for now.
@LGUG2Z commented on GitHub (Jun 22, 2022):
The desired behaviour move is now configurable and toggle-able:
komorebic cross-monitor-move-behaviour [swap, insert]komorebic toggle-cross-monitor-move-behaviourWith this I think the feature is almost done pending user testing on setups of 3+ monitors in different orientations.
@snide commented on GitHub (Jun 22, 2022):
Cool! I'll check this tonight.
@LGUG2Z commented on GitHub (Jun 27, 2022):
After some more testing I'm happy enough with the state of this to merge it into the
masterbranch. If there are any issues raised in the future I think it's better to fix them going forward on themasterbranch.