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

Missing workflows #95

New Issue
Closed
opened 2026-01-05 14:48:17 +01:00 by adam · 4 comments
adam commented 2026-01-05 14:48:17 +01:00
Owner
Copy Link

Originally created by @JJGO on GitHub (Jun 8, 2022).

Hi, thanks for creating komorebi, it's the best tiling window manager I've come across.

I've been a yabai user for a while and there are a few workflows I'm sorely missing. I've gone through the commands but I've not been able to find matching behaviour and would love advice on how to achieve similar results. Please do not take this as a feature request, I'm just trying to learn how to make komorebi ergonomical.

  • Is there a way to transpose a group in bsp? (columns to rows and viceversa, like yabai -m window --toggle split). Without this, I'm having a hard time having three columns in bsp mode.
  • Is there a way to have a 2x2 grid in bsp mode? In yabai I'd move with warp to prevent the movement from swapping but I'm not sure how to achieve that here.
  • Is there a way to resize a window using just the keyboard? (like yabai -m window --resize)
  • Is there a way to partial zoom a window (zoom into parent/child)? (like yabai -m window --toggle zoom-parent)

Lastly, what is the recommended way of dealing with Windows Desktops? Just use one and let komorebi handle workspaces?

Thank you

Originally created by @JJGO on GitHub (Jun 8, 2022). Hi, thanks for creating komorebi, it's the best tiling window manager I've come across. I've been a yabai user for a while and there are a few workflows I'm sorely missing. I've gone through the commands but I've not been able to find matching behaviour and would love advice on how to achieve similar results. Please do not take this as a feature request, I'm just trying to learn how to make komorebi ergonomical. - Is there a way to transpose a group in bsp? (columns to rows and viceversa, like `yabai -m window --toggle split`). Without this, I'm having a hard time having three columns in bsp mode. - Is there a way to have a 2x2 grid in bsp mode? In yabai I'd move with warp to prevent the movement from swapping but I'm not sure how to achieve that here. - Is there a way to resize a window using just the keyboard? (like `yabai -m window --resize`) - Is there a way to partial zoom a window (zoom into parent/child)? (like `yabai -m window --toggle zoom-parent`) Lastly, what is the recommended way of dealing with Windows Desktops? Just use one and let komorebi handle workspaces? Thank you
adam closed this issue 2026-01-05 14:48:17 +01:00
adam commented 2026-01-05 14:48:18 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 8, 2022):

You can resize with komorebic resize-edge [left, right, up, down] [increase, decrease] or komorebic resize-axis [horizontal, vertical] [increase, decrease] - these can be bound to the keyboard or the mouse; these days I mostly just bind resize-axis horizontal increase/decrease to alt + mwheel down/up.

No partial zooms because there is no tree (see below).

No 2x2 grids in bsp because there is no tree (see below), but this could be possible by extending what is possible with custom layouts (allowing primary columns to have multiple rows).

You could achieve various 3-column layouts with a custom layout (see attached image), but I don't think this really sounds like what you're looking for:

image

Bsp rotations (really, any tree manipulation operations) again aren't possible because komorebi stores windows in a Ring rather than a Tree. More context from another comment:

The layout engine is probably the biggest piece of technical debt in this project, and it comes down to the choice of data structure used to hold the windows (a Ring instead of a Tree). Because of this data structure choice, resizing has to be implemented separately for different layout.

I'd welcome a PR to migrate to a data structure that would allow for resizing to be implemented once for any layout (like a tree) from anyone braver than I when it comes to implementing data structures with cyclic references in Rust, but this is not something that I would have any interest in undertaking for myself.

Trees are pretty hard to implement well in Rust and trying to port a bspwm/yabai-style BSP tree data structure from C to Rust is unfortunately beyond both my (barely mentionable) knowledge of C (to understand how the original data structure works) and my knowledge of Rust (to reimplement it faithfully while satisfying the safety guarantees required by the compiler).

Although it would be quite a big architectural change, I would be willing to migrate komorebi to using a BSP tree as the foundational data structure to manage workspace state if someone with the requisite knowledge were able to provide a working example of a bspwm/yabai-style BSP tree in Rust either via a PR or by publishing a library.

@LGUG2Z commented on GitHub (Jun 8, 2022): You can resize with `komorebic resize-edge [left, right, up, down] [increase, decrease]` or `komorebic resize-axis [horizontal, vertical] [increase, decrease]` - these can be bound to the keyboard or the mouse; these days I mostly just bind `resize-axis horizontal increase/decrease` to alt + mwheel down/up. No partial zooms because there is no tree (see below). No 2x2 grids in bsp because there is no tree (see below), but this could be possible by extending what is possible with custom layouts (allowing primary columns to have multiple rows). You could achieve various 3-column layouts with a custom layout (see attached image), but I don't think this really sounds like what you're looking for: ![image](https://user-images.githubusercontent.com/13164844/172655291-cd57fd3d-4bf6-4fa6-b601-7612a5df8d18.png) Bsp rotations (really, any tree manipulation operations) again aren't possible because `komorebi` stores windows in a Ring rather than a Tree. More context from [another comment](https://github.com/LGUG2Z/komorebi/issues/150#issuecomment-1144206457): > > The layout engine is probably the biggest piece of technical debt in this project, and it comes down to the choice of data structure used to hold the windows (a Ring instead of a Tree). Because of this data structure choice, resizing has to be implemented separately for different layout. > > I'd welcome a PR to migrate to a data structure that would allow for resizing to be implemented once for any layout (like a tree) from anyone braver than I when it comes to implementing data structures with cyclic references in Rust, but this is not something that I would have any interest in undertaking for myself. [Trees are pretty hard to implement well in Rust](https://sachanganesh.com/programming/graph-tree-traversals-in-rust/) and trying to port a bspwm/yabai-style BSP tree data structure from C to Rust is unfortunately beyond both my (barely mentionable) knowledge of C (to understand how the original data structure works) and my knowledge of Rust (to reimplement it faithfully while satisfying the safety guarantees required by the compiler). Although it would be quite a big architectural change, I would be willing to migrate `komorebi` to using a BSP tree as the foundational data structure to manage workspace state if someone with the requisite knowledge were able to provide a working example of a bspwm/yabai-style BSP tree in Rust either via a PR or by publishing a library.
adam commented 2026-01-05 14:48:18 +01:00
Author
Owner
Copy Link

@JJGO commented on GitHub (Jun 8, 2022):

Thank you for the detailed write-up, it's very informative.

Love the trick of binding resize-axis to the mouse wheel, it's great. Added a shift variant for vertical resizing.

I understand the datastructure issue, it seems like a very nontrivial thing to pull off. I've been meaning to get familiar with Rust for a while but as a mostly Python programmer the borrow checker looks quite intimidating. I'd love to help with the ring to tree migration at some point but I feel it like I need to get my feet wet with Rust first. Hopefully there exists some good tree crate that can be (partially) reused.

In the meantime, the 3-column layout you describe seems useful and better than the column layout where >3 windows makes everything unusably narrow. I've tested it and I like how it deals with 3+ windows but it looks like now the resize-axis commands are not working. Do those commands only work in bsp mode?

@JJGO commented on GitHub (Jun 8, 2022): Thank you for the detailed write-up, it's very informative. Love the trick of binding resize-axis to the mouse wheel, it's great. Added a shift variant for vertical resizing. I understand the datastructure issue, it seems like a very nontrivial thing to pull off. I've been meaning to get familiar with Rust for a while but as a mostly Python programmer the borrow checker looks quite intimidating. I'd love to help with the ring to tree migration at some point but I feel it like I need to get my feet wet with Rust first. Hopefully there exists some good tree crate that can be (partially) reused. In the meantime, the 3-column layout you describe seems useful and better than the column layout where >3 windows makes everything unusably narrow. I've tested it and I like how it deals with 3+ windows but it looks like now the resize-axis commands are not working. Do those commands only work in bsp mode?
adam commented 2026-01-05 14:48:18 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 9, 2022):

In the meantime, the 3-column layout you describe seems useful and better than the column layout where >3 windows makes everything unusably narrow. I've tested it and I like how it deals with 3+ windows but it looks like now the resize-axis commands are not working. Do those commands only work in bsp mode?

The resize-axis command works with bsp and with custom layouts, with the caveat being that on custom layouts, the resize commands will only operate on the primary column:

- column: Secondary
  configuration:
    Horizontal: 2
- column: Primary
  configuration:
    WidthPercentage: 44
- column: Tertiary
  configuration: Horizontal

This is the custom layout that I mostly use- resize-axis [increase, decrease] will change the WidthPercentage of the Primary.

There is however one bug that I'm still trying to work out: If a custom layout is activated by a workspace layout rule then the resize-axis command currently does not work as intended.

@LGUG2Z commented on GitHub (Jun 9, 2022): > In the meantime, the 3-column layout you describe seems useful and better than the column layout where >3 windows makes everything unusably narrow. I've tested it and I like how it deals with 3+ windows but it looks like now the resize-axis commands are not working. Do those commands only work in bsp mode? The `resize-axis` command works with `bsp` and with custom layouts, with the caveat being that on custom layouts, the resize commands will only operate on the primary column: ``` - column: Secondary configuration: Horizontal: 2 - column: Primary configuration: WidthPercentage: 44 - column: Tertiary configuration: Horizontal ``` This is the custom layout that I mostly use- `resize-axis [increase, decrease]` will change the `WidthPercentage` of the `Primary`. There is however one bug that I'm still trying to work out: If a custom layout is activated by a [workspace layout rule](https://github.com/LGUG2Z/komorebi/#dynamically-changing-layouts-based-on-number-of-visible-window-containers) then the `resize-axis` command currently does not work as intended.
adam commented 2026-01-05 14:48:18 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 15, 2022):

The bug related to the resizing of a primary column in a custom layout activated by a layout rule has been fixed on master. 🎉

@LGUG2Z commented on GitHub (Jun 15, 2022): The bug related to the resizing of a primary column in a custom layout activated by a layout rule has been fixed on `master`. 🎉
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
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#95
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?