starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[BUG]: focused_container ignores monocle containers #383

New Issue
Closed
opened 2026-01-05 14:50:13 +01:00 by adam · 2 comments
adam commented 2026-01-05 14:50:13 +01:00
Owner
Copy Link

Originally created by @alex-ds13 on GitHub (May 21, 2024).

Describe the bug
Most commands that relate to the focused window don't take into account if a monocle is open or not. For example if you have 2 windows on a workspace, then set one of them to a monocle and then send the close command, the window on the monocle stays open and it is the other one (the hidden one) that gets closed. From what I understand the issue is that these commands call focused_window which then calls focused_container which reads directly from containers without looking first if there is a monocle container and so it returns the wrong window.

The problem seems to be that workspace's containers use a Ring<Container> which implements it's own focused_container function that simply gets the focused one from the containers vec. However when toggling a monocle the container that is used for the monocle is removed from the containers vec. Maybe the focused_container function needs to be implemented as a new function on the workspace so that it can properly check for monocle containers, or the monocle container shouldn't remove the container and simply have its index stored (@LGUG2Z is it really necessary to remove it?).

To Reproduce
Steps to reproduce the behavior:

  1. Start komorebi
  2. Open two windows
  3. Call the monocle command (with "alt + shit + f" for example)
  4. Call the close command (with "alt + q" for example)
  5. Window on monocle stays open
  6. Toggle monocle (with "alt + shit + f" again)
  7. See that the other window is gone

Expected behavior
The focused window on the monocle should be the one to be closed, not the other one.

Screenshots and Videos
Add screenshots and videos to help explain your problem.

Operating System
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631

komorebic check Output
KOMOREBI_CONFIG_HOME detected: C:\Users\Alex\.config\komorebi

Looking for configuration files in C:\Users\Alex\.config\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\Alex\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

Additional context
I'm currently using the master version. I'm not sure if the bug is present on previous versions.

Originally created by @alex-ds13 on GitHub (May 21, 2024). **Describe the bug** Most commands that relate to the focused window don't take into account if a monocle is open or not. For example if you have 2 windows on a workspace, then set one of them to a monocle and then send the close command, the window on the monocle stays open and it is the other one (the hidden one) that gets closed. From what I understand the issue is that these commands call `focused_window` which then calls `focused_container` which reads directly from containers without looking first if there is a monocle container and so it returns the wrong window. The problem seems to be that workspace's `containers` use a `Ring<Container>` which implements it's own `focused_container` function that simply gets the focused one from the `containers` vec. However when toggling a monocle the container that is used for the monocle is removed from the `containers` vec. Maybe the `focused_container` function needs to be implemented as a new function on the workspace so that it can properly check for monocle containers, or the monocle container shouldn't remove the container and simply have its index stored (@LGUG2Z is it really necessary to remove it?). **To Reproduce** Steps to reproduce the behavior: 1. Start komorebi 2. Open two windows 3. Call the monocle command (with "alt + shit + f" for example) 4. Call the close command (with "alt + q" for example) 5. Window on monocle stays open 6. Toggle monocle (with "alt + shit + f" again) 7. See that the other window is gone **Expected behavior** The focused window on the monocle should be the one to be closed, not the other one. **Screenshots and Videos** Add screenshots and videos to help explain your problem. **Operating System** OS Name: Microsoft Windows 11 Pro OS Version: 10.0.22631 N/A Build 22631 **`komorebic check` Output** KOMOREBI_CONFIG_HOME detected: C:\Users\Alex\\.config\komorebi Looking for configuration files in C:\Users\Alex\\.config\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\Alex\\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag **Additional context** I'm currently using the master version. I'm not sure if the bug is present on previous versions.
adam added the bug label 2026-01-05 14:50:13 +01:00
adam closed this issue 2026-01-05 14:50:14 +01:00
adam commented 2026-01-05 14:50:14 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 21, 2024):

Both the Close and the Minimize handlers should be making calls from the Workspace rather than the Window to check for monocle, maximized and floating windows before looking at managed windows; I'll update this before the next release.

@LGUG2Z commented on GitHub (May 21, 2024): Both the Close and the Minimize handlers should be making calls from the Workspace rather than the Window to check for monocle, maximized and floating windows before looking at managed windows; I'll update this before the next release.
adam commented 2026-01-05 14:50:14 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (May 21, 2024):

Both the Close and the Minimize handlers should be making calls from the Workspace rather than the Window to check for monocle, maximized and floating windows before looking at managed windows; I'll update this before the next release.

Thank you! The query commands for focused-container and focused-window might need to be changed as well to do the same, but that isn't that important since it is just a query.

@alex-ds13 commented on GitHub (May 21, 2024): > Both the Close and the Minimize handlers should be making calls from the Workspace rather than the Window to check for monocle, maximized and floating windows before looking at managed windows; I'll update this before the next release. Thank you! The query commands for `focused-container` and `focused-window` might need to be changed as well to do the same, but that isn't that important since it is just a query.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#383
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?