Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Focus on monitor if there are no more apps left to focus #145

Closed
jrmallorca opened this issue May 23, 2022 · 9 comments
Closed
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@jrmallorca
Copy link

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
Copy link

snide commented Jun 14, 2022

Coming from Linux tiling window managers this was something I immediately missed as well. Similarly, you'd expect the move command in komorebi to do something similar. If the focused application was on the right edge of a monitor, and you move right it 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
Copy link
Owner

LGUG2Z commented Jun 15, 2022

image

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 LGUG2Z self-assigned this Jun 15, 2022
@LGUG2Z LGUG2Z added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Jun 15, 2022
LGUG2Z added a commit that referenced this issue Jun 21, 2022
This commit introduces the ability to operate across monitor boundaries
with the 'move' and 'focus' commands.

When operating down or to the right, the target index of the monitor in
that direction will be 0. When operating up or to the left, the target
index will either be len() - 1 if focusing, or len() if moving.

re #145
@LGUG2Z
Copy link
Owner

LGUG2Z commented 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
Copy link

snide commented 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
Copy link
Owner

LGUG2Z commented 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 focus changes across monitors to revert to the last focused tile on the target monitor, and also modify the move changes 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 added a commit that referenced this issue Jun 21, 2022
This commit ensures that when focusing across a monitor boundary, the
focus will go to the last focused window container on the focused
workspace on the other side of a given window boundary.

re #145
@LGUG2Z
Copy link
Owner

LGUG2Z commented Jun 21, 2022

Changing a move into a swap is a lot more difficult than I thought. 😅

Putting it on the backburner for now.

LGUG2Z added a commit that referenced this issue Jun 21, 2022
This commit ensures that when moving across a monitor boundary, the
origin window container will be swapped with the last focused window
container on the other side of the monitor boundary.

If there is no window container on the other side of the window
boundary, it will be treated as a move instead of a swap.

re #145
LGUG2Z added a commit that referenced this issue Jun 21, 2022
This commit provides two new commands, to set and toggle the behaviour
(swap, insert) when moving window containers across monitor boundaries.
MoveBehaviour::Swap has been selected as the default as this seems to be
the default on bspwm.

re #145
@LGUG2Z
Copy link
Owner

LGUG2Z commented Jun 21, 2022

The desired behaviour move is now configurable and toggle-able:

  • komorebic cross-monitor-move-behaviour [swap, insert]
  • komorebic toggle-cross-monitor-move-behaviour

With this I think the feature is almost done pending user testing on setups of 3+ monitors in different orientations.

@snide
Copy link

snide commented Jun 21, 2022

Cool! I'll check this tonight.

LGUG2Z added a commit that referenced this issue Jun 27, 2022
This commit introduces the ability to operate across monitor boundaries
with the 'move' and 'focus' commands.

When operating down or to the right, the target index of the monitor in
that direction will be 0. When operating up or to the left, the target
index will either be len() - 1 if focusing, or len() if moving.

re #145
LGUG2Z added a commit that referenced this issue Jun 27, 2022
This commit ensures that when focusing across a monitor boundary, the
focus will go to the last focused window container on the focused
workspace on the other side of a given window boundary.

re #145
LGUG2Z added a commit that referenced this issue Jun 27, 2022
This commit ensures that when moving across a monitor boundary, the
origin window container will be swapped with the last focused window
container on the other side of the monitor boundary.

If there is no window container on the other side of the window
boundary, it will be treated as a move instead of a swap.

re #145
LGUG2Z added a commit that referenced this issue Jun 27, 2022
This commit provides two new commands, to set and toggle the behaviour
(swap, insert) when moving window containers across monitor boundaries.
MoveBehaviour::Swap has been selected as the default as this seems to be
the default on bspwm.

re #145
@LGUG2Z LGUG2Z closed this as completed in 3c84bfd Jun 27, 2022
@LGUG2Z
Copy link
Owner

LGUG2Z commented Jun 27, 2022

After some more testing I'm happy enough with the state of this to merge it into the master branch. If there are any issues raised in the future I think it's better to fix them going forward on the master branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants