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:
Start komorebi
Open two windows
Call the monocle command (with "alt + shit + f" for example)
Call the close command (with "alt + q" for example)
Window on monocle stays open
Toggle monocle (with "alt + shit + f" again)
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
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
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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_windowwhich then callsfocused_containerwhich 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
containersuse aRing<Container>which implements it's ownfocused_containerfunction that simply gets the focused one from thecontainersvec. However when toggling a monocle the container that is used for the monocle is removed from thecontainersvec. Maybe thefocused_containerfunction 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:
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 checkOutputKOMOREBI_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.
@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.
@alex-ds13 commented on GitHub (May 21, 2024):
Thank you! The query commands for
focused-containerandfocused-windowmight need to be changed as well to do the same, but that isn't that important since it is just a query.