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

[PR #1006] [CLOSED] Feature: handle windows that match any float_rules as float instead of being ignored #1169

New Issue
Closed
opened 2026-01-05 14:54:20 +01:00 by adam · 0 comments
adam commented 2026-01-05 14:54:20 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1006
Author: @alex-ds13
Created: 9/24/2024
Status: ❌ Closed

Base: master ← Head: feature/float-rules-as-float

📝 Commits (3)

  • 5c52feb feat(wm): add new window_container_behaviour option
  • 9498489 feat(cli): add new window_container_behaviour commands
  • 10772a7 feat(wm): stop ignoring windows matched by float_rules

📊 Changes

6 files changed (+73 additions, -11 deletions)

View changed files

📝 komorebi-client/src/lib.rs (+1 -0)
📝 komorebi/src/core/mod.rs (+4 -0)
📝 komorebi/src/process_command.rs (+30 -6)
📝 komorebi/src/process_event.rs (+17 -3)
📝 komorebi/src/window_manager.rs (+2 -1)
📝 komorebic/src/main.rs (+19 -1)

📄 Description

This PR builds on top of the #986

This PR requires the WindowContainerBehaviour::Float introduced on that PR, as such it includes the commits from that PR as well. The fix suggested from this PR is just the last commit, so in order to ignore the bigger changes from the other PR it is best to look just at the changes from the last commit (they are quite simple...)

WHAT DOES THIS PR DO?

  • It makes it so windows matched by any floating rule won't simply be ignored by komorebi, but
    instead it will still handle the window by using the WindowContainerBehaviour::Float introduced
    on the other PR mentioned above.
    This means that those windows will still be tied to a specific workspace and only be shown on that
    workspace instead of showing everywhere.
    This would fix issues like the #990 one.

  • There is one thing that almost everyone asks for when first starting using komorebi, which is a way
    to restart komorebi with the current state. I believe that this hasn't been implemented yet in part
    because there was no good way to handle the cases where a monitor no longer exists when restarting
    again. (@LGUG2Z feel free to correct me if this isn't the case and there are other issues with it)
    These PRs could make it so we would be able to restart with the previous state and any window that was
    on a no longer existing monitor could be opened on the currently focused workspace as floating. This
    way the user would immediately see all the windows that couldn't be handled and they can manually move
    them to wherever they like.
    This is just an idea and I've haven't implemented nor tried to do so on these PR's yet!

ISSUES OR QUESTIONS WITH THIS PR

  • The windows set to floating by a floating rule can still become managed by using the command
    toggle-float or by moving them to another workspace that is tiled. This might not be wanted,
    since this windows were added to said rule usually because they don't behave well when tiled.
    This can probably be fixed by either having another vector on the workspace (like floating_windows
    and forced_floating_windows) or by changing the floating_windows vector to have a wrapping struct
    that holds the window and some info:

       struct FloatingWindow {
       window: Window,
       forced: bool,
   }

  • There might still be a need to create a ignored_rules along with the current float_rules since there might be some apps that really need to be ignored, or that a user might prefer to have ignored instead of being handled as Float.

  • Currently, floating_windows aren't properly handled by commands, most commands when called
    check for the focused container, however the floating windows are never set to focused so this
    will result in a lot of users complaining that the floating windows are being ignored when they
    try to do some operation on them but instead that operation is applied to the previously managed
    focused window instead. This should probably be fixed before any of this is merged to master.

  • Currently, when changing workspaces the newly focused workspace shows the focused container last,
    meaning that if some floating window was on top before you changed to another workspace, now it
    will show behind the focused container.
    Allowing floating_windows to be focusable like mentioned above would fix this issue.
    This would fix issues like #984

  • Some questions that need to be answered before pushing with this:

    1. Should a window that is floating become tiled when moved to another workspace?
    2. Should a rule enforcing a window on a specific workspace check the WindowContainerBehaviour
      before moving the window and creating a tiled container for it?
    3. Should floating windows be focusable?
    4. Should there be a WindowContainerBehaviour per workspace? (this might be out of the scope
      of this PR but it is related to this so I decided to leave the question here anyway)

TODO

  • Currently this PR is just a draft because I'm merely checking if the windows that have a should_manage = false were windows that matched a floating rule identifier and if that is the case I force the WindowContainerBehaviour::Float when they are created. But this could probably be better handled if instead of returning a bool from the should_manage() function we returned some:
enum ShouldManageResult {
    Ignore,
    Tile,
    Float,
}

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/LGUG2Z/komorebi/pull/1006 **Author:** [@alex-ds13](https://github.com/alex-ds13) **Created:** 9/24/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `feature/float-rules-as-float` --- ### 📝 Commits (3) - [`5c52feb`](https://github.com/LGUG2Z/komorebi/commit/5c52febc4c541c3eecb37bbbd3a7ca1d0e504a1f) feat(wm): add new window_container_behaviour option - [`9498489`](https://github.com/LGUG2Z/komorebi/commit/9498489d0678dee737a2efc6bd85acb5bb02d9cc) feat(cli): add new window_container_behaviour commands - [`10772a7`](https://github.com/LGUG2Z/komorebi/commit/10772a7690df3dbe844e31a68845938e3b7e107c) feat(wm): stop ignoring windows matched by float_rules ### 📊 Changes **6 files changed** (+73 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `komorebi-client/src/lib.rs` (+1 -0) 📝 `komorebi/src/core/mod.rs` (+4 -0) 📝 `komorebi/src/process_command.rs` (+30 -6) 📝 `komorebi/src/process_event.rs` (+17 -3) 📝 `komorebi/src/window_manager.rs` (+2 -1) 📝 `komorebic/src/main.rs` (+19 -1) </details> ### 📄 Description ## This PR builds on top of the #986 This PR requires the `WindowContainerBehaviour::Float` introduced on that PR, as such it includes the commits from that PR as well. The fix suggested from this PR is just the last commit, so in order to ignore the bigger changes from the other PR it is best to look just at the changes from the last commit (they are quite simple...) ## WHAT DOES THIS PR DO? - It makes it so windows matched by any floating rule won't simply be ignored by komorebi, but instead it will still handle the window by using the `WindowContainerBehaviour::Float` introduced on the other PR mentioned above. This means that those windows will still be tied to a specific workspace and only be shown on that workspace instead of showing everywhere. This would fix issues like the #990 one. - There is one thing that almost everyone asks for when first starting using komorebi, which is a way to restart komorebi with the current state. I believe that this hasn't been implemented yet in part because there was no good way to handle the cases where a monitor no longer exists when restarting again. *(@LGUG2Z feel free to correct me if this isn't the case and there are other issues with it)* These PRs could make it so we would be able to restart with the previous state and any window that was on a no longer existing monitor could be opened on the currently focused workspace as floating. This way the user would immediately see all the windows that couldn't be handled and they can manually move them to wherever they like. ***This is just an idea and I've haven't implemented nor tried to do so on these PR's yet!*** ## ISSUES OR QUESTIONS WITH THIS PR - The windows set to floating by a floating rule can still become managed by using the command `toggle-float` or by moving them to another workspace that is tiled. This might not be wanted, since this windows were added to said rule usually because they don't behave well when tiled. This can probably be fixed by either having another vector on the workspace (like `floating_windows` and `forced_floating_windows`) or by changing the `floating_windows` vector to have a wrapping struct that holds the window and some info: ```rust struct FloatingWindow { window: Window, forced: bool, } ``` - There might still be a need to create a `ignored_rules` along with the current `float_rules` since there might be some apps that really need to be ignored, or that a user might prefer to have ignored instead of being handled as `Float`. - Currently, `floating_windows` aren't properly handled by commands, most commands when called check for the focused container, however the floating windows are never set to focused so this will result in a lot of users complaining that the floating windows are being ignored when they try to do some operation on them but instead that operation is applied to the previously managed focused window instead. This should probably be fixed before any of this is merged to master. - Currently, when changing workspaces the newly focused workspace shows the focused container last, meaning that if some floating window was on top before you changed to another workspace, now it will show behind the focused container. Allowing `floating_windows` to be focusable like mentioned above would fix this issue. This would fix issues like #984 - Some questions that need to be answered before pushing with this: 1) Should a window that is floating become tiled when moved to another workspace? 2) Should a rule enforcing a window on a specific workspace check the `WindowContainerBehaviour` before moving the window and creating a tiled container for it? 3) Should floating windows be focusable? 4) Should there be a `WindowContainerBehaviour` per workspace? (this might be out of the scope of this PR but it is related to this so I decided to leave the question here anyway) ## TODO - Currently this PR is just a draft because I'm merely checking if the windows that have a `should_manage = false` were windows that matched a floating rule identifier and if that is the case I force the `WindowContainerBehaviour::Float` when they are created. But this could probably be better handled if instead of returning a bool from the `should_manage()` function we returned some: ```rust enum ShouldManageResult { Ignore, Tile, Float, } ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-01-05 14:54:20 +01:00
adam closed this issue 2026-01-05 14:54:20 +01:00
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 pull-request
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#1169
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?