[FEAT]: Stacking rules #219

New Issue

2026-01-05T14:49:04+01:00

adam commented

2026-01-05 14:49:04 +01:00

Originally created by @LGUG2Z on GitHub (Jun 9, 2023).

Is your feature request related to a problem? Please describe.
These days, instead of using multiple workspaces, I like to keep apps of the same "category" in a stack. For example, I like to keep Firefox and Chrome in a stack, Windows Terminal and WezTerm in a stack, and then alt+] to cycle between them. Now, after every restart, I have to manually recreate these stacks which is a little annoying.

Describe the solution you'd like
I would like to be able to define stacking rules, so that every time I open Chrome, it checks if Firefox is open somewhere, and if it is, instead of creating a new container, it gets added to the container stack that Firefox is in, and vice-versa.

Describe alternatives you've considered
Just doing it manually every time. I don't restart often, but still, this would be nice.

Additional context
It might make sense to be able to optionally name containers, and then have the rule be a mapping of applications to containers.

Originally created by @LGUG2Z on GitHub (Jun 9, 2023). **Is your feature request related to a problem? Please describe.** These days, instead of using multiple workspaces, I like to keep apps of the same "category" in a stack. For example, I like to keep Firefox and Chrome in a stack, Windows Terminal and WezTerm in a stack, and then alt+] to cycle between them. Now, after every restart, I have to manually recreate these stacks which is a little annoying. **Describe the solution you'd like** I would like to be able to define stacking rules, so that every time I open Chrome, it checks if Firefox is open somewhere, and if it is, instead of creating a new container, it gets added to the container stack that Firefox is in, and vice-versa. **Describe alternatives you've considered** Just doing it manually every time. I don't restart often, but still, this would be nice. **Additional context** It might make sense to be able to optionally name containers, and then have the rule be a mapping of applications to containers.

adam added the enhancement i-will-probably-work-on-this komorebi labels 2026-01-05 14:49:04 +01:00

adam commented

2026-01-05 14:49:05 +01:00

@bzm3r commented on GitHub (Jul 29, 2023):

@LGUG2Z I'd be happy to help work on this, as I find myself in a similar situation.

More specifically: my screen is small enough that I want just two columns in my default workspace (with a single row): which means that both columns are primarily stacks, and thus, auto-stacking would be nice.

I'm new to komorebi, so I'm customizing little things day-by-day, rather than all at once (overwhelming). From my current understanding of the lay-of-the-land: stacking rules are an extension of workspace layout rules? That is: they would be used to help further specify how a particular workspace layout rule works in the corresponding .yaml?

@bzm3r commented on GitHub (Jul 29, 2023): @LGUG2Z I'd be happy to help work on this, as I find myself in a similar situation. More specifically: my screen is small enough that I want just two columns in my default workspace (with a single row): which means that both columns are primarily stacks, and thus, auto-stacking would be nice. I'm new to `komorebi`, so I'm customizing little things day-by-day, rather than all at once (overwhelming). From my current understanding of the lay-of-the-land: stacking rules are an extension of workspace layout rules? That is: they would be used to help further specify how a particular workspace layout rule works in the corresponding `.yaml`?

adam commented

2026-01-05 14:49:05 +01:00

@LGUG2Z commented on GitHub (Feb 24, 2024):

This is an implementation that has been merged into a hard-fork of komorebi. I'm not sure this is the way I'd like to go about this at a configuration-level as I imagine this to be more granular on a per-monitor basis (ie. the ability to autostack applications on one workspace but not on another)

https://github.com/LGUG2Z/komorebi/pull/666/files

@LGUG2Z commented on GitHub (Feb 24, 2024): This is an implementation that has been merged into a hard-fork of `komorebi`. I'm not sure this is the way I'd like to go about this at a configuration-level as I imagine this to be more granular on a per-monitor basis (ie. the ability to autostack applications on one workspace but not on another) https://github.com/LGUG2Z/komorebi/pull/666/files

adam commented

2026-01-05 14:49:05 +01:00

@ECon65 commented on GitHub (Sep 5, 2024):

Is it possible to provide this feature using either

window_container_behaviour as a workspace item parameter?
creating new "stack-all" layout for workspace item?

both options would allow us to configure certain workspaces as stacks statically in the json file.

I can just imagine that it would be easier to implement than per application rule.

@ECon65 commented on GitHub (Sep 5, 2024): Is it possible to provide this feature using either - `window_container_behaviour` as a workspace item parameter? - creating new "stack-all" layout for workspace item? both options would allow us to configure certain workspaces as stacks statically in the json file. I can just imagine that it would be easier to implement than per application rule.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#219