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

Feature request: Allow for bspwm-style window tiling based on currently focused window #51

New Issue
Closed
opened 2026-01-05 14:47:56 +01:00 by adam · 1 comment
adam commented 2026-01-05 14:47:56 +01:00
Owner
Copy Link

Originally created by @da-rth on GitHub (Oct 29, 2021).

Currently, komorebi applies a 'right-most window' tiling method for its bsp layout when a new window is moved to/opened on a workspace. This means that there is currently no way to have nested window layouts on the top/bottom left and top right of the areas of the screen.

I would like to request that komorebi may implement the bspwm-style window tiling method which splits based on the location of the currently focused window. Please see the attached video of an example of the requested behaviour implemented in swaywm:

https://user-images.githubusercontent.com/10499053/139394490-7b4d6dc7-bfb9-4021-9e42-90a037bfd56a.mp4

Note:

  • 00:00 to 00:06 illustrates how all tiling is handled in komorebi via the right-most window method.
  • 00:07 on-wards illustrates tiling windows based on the currently focused window
Originally created by @da-rth on GitHub (Oct 29, 2021). Currently, komorebi applies a 'right-most window' tiling method for its bsp layout when a new window is moved to/opened on a workspace. This means that there is currently no way to have nested window layouts on the top/bottom left and top right of the areas of the screen. I would like to request that komorebi may implement the bspwm-style window tiling method which splits based on the location of the currently focused window. Please see the attached video of an example of the requested behaviour implemented in swaywm: https://user-images.githubusercontent.com/10499053/139394490-7b4d6dc7-bfb9-4021-9e42-90a037bfd56a.mp4 Note: - 00:00 to 00:06 illustrates how all tiling is handled in komorebi via the right-most window method. - 00:07 on-wards illustrates tiling windows based on the currently focused window
adam added the enhancementi-will-not-work-on-this labels 2026-01-05 14:47:56 +01:00
adam closed this issue 2026-01-05 14:47:56 +01:00
adam commented 2026-01-05 14:47:56 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 29, 2021):

The big prerequisite for this kind of feature is being able to seamlessly translate between Vec-like and Tree-like data structures for container state.

Right now, komorebi uses a Ring data structure, which is a wrapper around a VecDeque which also tracks a focused index (it is the responsibility of the mutator to ensure that this index is updated).

Ideally we would have a tree data structure that can be created from and can create a Ring (implementing From), then we would be able to re-use (or translate) a lot of the existing layout generation logic from other window managers that allow any node to be considered the root of a tree (as shown in the SwayWM video).

I'm pretty far removed from my last DS&A class and I (luckily) have never had to grind Leetcode so I'm pretty out of practice here when it comes to implementing a binary space partition tree from scratch (especially one that plays nice with Rust's borrow checker), but I am happy to review any contributions to add a true BSP data structure to komorebi to enable this and other features in the future.

@LGUG2Z commented on GitHub (Oct 29, 2021): The big prerequisite for this kind of feature is being able to seamlessly translate between Vec-like and Tree-like data structures for container state. Right now, `komorebi` uses a [`Ring`](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/ring.rs#L6) data structure, which is a wrapper around a [VecDeque ](https://doc.rust-lang.org/std/collections/struct.VecDeque.html) which also tracks a focused index (it is the responsibility of the mutator to ensure that this index is updated). Ideally we would have a tree data structure that can be created from and can create a Ring (implementing [From](https://doc.rust-lang.org/std/convert/trait.From.html)), then we would be able to re-use (or translate) a lot of the existing layout generation logic from other window managers that allow any node to be considered the root of a tree (as shown in the SwayWM video). I'm pretty far removed from my last DS&A class and I (luckily) have never had to grind Leetcode so I'm pretty out of practice here when it comes to implementing a binary space partition tree from scratch (especially one that plays nice with Rust's borrow checker), but I am happy to review any contributions to add a true BSP data structure to `komorebi` to enable this and other features in the future.
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 enhancement i-will-not-work-on-this
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#51
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?