Feature request: tabbed columns #60

Originally created by @diocletiann on GitHub (Nov 11, 2021).

Originally assigned to: @LGUG2Z on GitHub.

My eyesight isn't what used to be and I'm using 125% scaling with lots of zoom and headed for 150%. Therefore I end up with full height columns 99% of the time. Is it possible to get tab support for columns like i3? Ideally, the next window would open in a new tab in the adjacent column to avoid obscuring the active window.

Originally created by @diocletiann on GitHub (Nov 11, 2021). Originally assigned to: @LGUG2Z on GitHub. My eyesight isn't what used to be and I'm using 125% scaling with lots of zoom and headed for 150%. Therefore I end up with full height columns 99% of the time. Is it possible to get tab support for columns like i3? Ideally, the next window would open in a new tab in the adjacent column to avoid obscuring the active window.

adam added the enhancement label 2026-01-05 14:47:58 +01:00

adam closed this issue

adam commented

@LGUG2Z commented on GitHub (Nov 12, 2021):

Could you provide an example screenshot/gif of this? I'm not familiar with i3 and I wasn't able to Google up a good example because I'm not 100% sure what I'm looking for.

@LGUG2Z commented on GitHub (Nov 12, 2021): Could you provide an example screenshot/gif of this? I'm not familiar with i3 and I wasn't able to Google up a good example because I'm not 100% sure what I'm looking for.

adam commented

@diocletiann commented on GitHub (Nov 12, 2021):

Sure. My i3 setup isn't scaling correctly right now, but here is an example of the same tabbed columns setup in PoP Shell. You'll see the tabs on top of each pane. Excuse the large photo, Linux scaling is a mess.

@diocletiann commented on GitHub (Nov 12, 2021): Sure. My i3 setup isn't scaling correctly right now, but here is an example of the same tabbed columns setup in PoP Shell. You'll see the tabs on top of each pane. Excuse the large photo, Linux scaling is a mess. ![Screenshot from 2021-11-12 13-29-51](https://user-images.githubusercontent.com/14058796/141517401-54634874-f0ab-4056-86a6-b2e4af92540f.png)

adam commented

@LGUG2Z commented on GitHub (Nov 12, 2021):

Ah, I see what you mean now. You can do 90% of this with the following commands:

stack                         Stack the focused window in the specified direction
unstack                       Unstack the focused window
cycle-stack                   Cycle the focused stack in the specified cycle direction

What komorebi doesn't have right now as an indicator for how many windows are in a stack, what their titles are etc.

Adding these kinds of visual elements to komorebi isn't something that I will be able to work in the near future, but I'm open both to PRs that implement this, and also to people trying to add these kind of visual elements using the new event subscriptions in whatever languages they are comfortable with (maybe something similar to Stackline for yabai).

@LGUG2Z commented on GitHub (Nov 12, 2021): Ah, I see what you mean now. You can do 90% of this with the following commands: ``` stack Stack the focused window in the specified direction unstack Unstack the focused window cycle-stack Cycle the focused stack in the specified cycle direction ``` What komorebi doesn't have right now as an indicator for how many windows are in a stack, what their titles are etc. Adding these kinds of visual elements to `komorebi` isn't something that I will be able to work in the near future, but I'm open both to PRs that implement this, and also to people trying to add these kind of visual elements using the new [event subscriptions](https://github.com/LGUG2Z/komorebi#window-manager-event-subscriptions) in whatever languages they are comfortable with (maybe something similar to [Stackline](https://github.com/AdamWagner/stackline) for yabai).

adam commented

@diocletiann commented on GitHub (Nov 12, 2021):

Thanks for the feedback. When you issue stack command, what is meant by direction? Is it the destination pane?

@diocletiann commented on GitHub (Nov 12, 2021): Thanks for the feedback. When you issue stack command, what is meant by direction? Is it the destination pane?

adam commented

@LGUG2Z commented on GitHub (Nov 12, 2021):

Yes, the direction is the destination pane:

komorebic.exe-stack

Stack the focused window in the specified direction

USAGE:
    komorebic.exe stack <OPERATION_DIRECTION>

ARGS:
    <OPERATION_DIRECTION>    [possible values: left, right, up, down]

OPTIONS:
    -h, --help    Print help information

There are also validations in place so that for example, if you try to stack to the right and you are focused on the right-most window on the screen, it will ultimately be a no-op.

komorebic.exe-cycle-stack

Cycle the focused stack in the specified cycle direction

USAGE:
    komorebic.exe cycle-stack <CYCLE_DIRECTION>

ARGS:
    <CYCLE_DIRECTION>
            [possible values: previous, next]

OPTIONS:
    -h, --help    Print help information

Once you have created a stack of more than one window you can go backwards and forwards through the stack with shortcuts for these commands. Commands that take a CYCLE_DIRECTION loop around, so if you try to go next when on the last element in a window stack, it will loop back around to the first element.

@LGUG2Z commented on GitHub (Nov 12, 2021): Yes, the direction is the destination pane: ``` komorebic.exe-stack Stack the focused window in the specified direction USAGE: komorebic.exe stack <OPERATION_DIRECTION> ARGS: <OPERATION_DIRECTION> [possible values: left, right, up, down] OPTIONS: -h, --help Print help information ``` There are also validations in place so that for example, if you try to stack to the right and you are focused on the right-most window on the screen, it will ultimately be a no-op. ``` komorebic.exe-cycle-stack Cycle the focused stack in the specified cycle direction USAGE: komorebic.exe cycle-stack <CYCLE_DIRECTION> ARGS: <CYCLE_DIRECTION> [possible values: previous, next] OPTIONS: -h, --help Print help information ``` Once you have created a stack of more than one window you can go backwards and forwards through the stack with shortcuts for these commands. Commands that take a `CYCLE_DIRECTION` loop around, so if you try to go `next` when on the last element in a window stack, it will loop back around to the first element.

adam commented

@diocletiann commented on GitHub (Nov 12, 2021):

Thanks! I'll try when I get reboot back into windows. Is there a way for new windows to be stacked automatically? The idea is to have a 2-3 column layout and alternate stacking new windows. Happy to settle for 2 if it makes the logic easier. That way you can always see the new window and its parent, and they both get a fair amount of space.

@diocletiann commented on GitHub (Nov 12, 2021): Thanks! I'll try when I get reboot back into windows. Is there a way for new windows to be stacked automatically? The idea is to have a 2-3 column layout and alternate stacking new windows. Happy to settle for 2 if it makes the logic easier. That way you can always see the new window and its parent, and they both get a fair amount of space.

adam commented

@LGUG2Z commented on GitHub (Nov 12, 2021):

This is a pretty cool idea that I hadn't thought about before.

I think it should be possible, I'll spend some time thinking about what the model for this should be as it is a little different to the current dynamic tiling model where new windows should be appended independently to a workspace infinitely.

@LGUG2Z commented on GitHub (Nov 12, 2021): This is a pretty cool idea that I hadn't thought about before. I think it should be possible, I'll spend some time thinking about what the model for this should be as it is a little different to the current dynamic tiling model where new windows should be appended independently to a workspace infinitely.

adam commented

@pigmej commented on GitHub (Nov 12, 2021):

Notion and ion3 implement that logic/model.

I think that it's the most optimal way to manage windows honestly. But obviously a bit extravagant.

@pigmej commented on GitHub (Nov 12, 2021): Notion and ion3 implement that logic/model. I think that it's the most optimal way to manage windows honestly. But obviously a bit extravagant.

adam commented

@diocletiann commented on GitHub (Nov 12, 2021):

I'll check out Notion. And yes, I basically want the ACME of window managers (with tabs instead of full rows).

@diocletiann commented on GitHub (Nov 12, 2021): I'll check out Notion. And yes, I basically want the ACME of window managers (with tabs instead of full rows).

adam commented

@LGUG2Z commented on GitHub (Nov 13, 2021):

@restfuladi I've added a command that lets you toggle on and off behaviour that causes new windows to be stacked on top of the currently focused window.

For the workflow you were describing, you could enable the columns layout, and when you have two windows open on the screen, change the new window behaviour to append-to-focused-container; this will ensure that any new windows opened will be stacked on top of whichever window container you are currently focused on instead of adding further containers to the columnar layout.

@LGUG2Z commented on GitHub (Nov 13, 2021): @restfuladi I've added a command that lets you toggle on and off behaviour that causes new windows to be stacked on top of the currently focused window. For the workflow you were describing, you could enable the columns layout, and when you have two windows open on the screen, change the new window behaviour to `append-to-focused-container`; this will ensure that any new windows opened will be stacked on top of whichever window container you are currently focused on instead of adding further containers to the columnar layout.

adam commented

@diocletiann commented on GitHub (Nov 14, 2021):

It works and you can even drag the new window to the adjacent container! It remembers the focused container even when using the PowerToys launcher btw.

This almost perfect, is it possible to have the new window stack in the adjacent container? It would save the step of moving the new window to the adjacent container.

Thanks!

@diocletiann commented on GitHub (Nov 14, 2021): It works and you can even drag the new window to the adjacent container! It remembers the focused container even when using the PowerToys launcher btw. This almost perfect, is it possible to have the new window stack in the adjacent container? It would save the step of moving the new window to the adjacent container. Thanks!

adam commented

@diocletiann commented on GitHub (Nov 14, 2021):

I'm seeing some odd behavior with windows disappearing (including from the taskbar and alt-tab screen) then re-appearing. I also just saw the two stacks switch positions when closing a window.

@diocletiann commented on GitHub (Nov 14, 2021): I'm seeing some odd behavior with windows disappearing (including from the taskbar and alt-tab screen) then re-appearing. I also just saw the two stacks switch positions when closing a window.

adam commented

@LGUG2Z commented on GitHub (Nov 15, 2021):

It works and you can even drag the new window to the adjacent container! It remembers the focused container even when using the PowerToys launcher btw.

I think this is actually undefined behaviour in action which is causing the later issues you describe; I think that when append-to-container is enabled, the handler for moving should carry out movements between containers where possible instead of swapping (which is what the handler is doing now). I'll try to work on this in the next days.

I'm seeing some odd behavior with windows disappearing (including from the taskbar and alt-tab screen) then re-appearing. I also just saw the two stacks switch positions when closing a window.

I'm not sure about the container stack switching, but the windows disappearing from the taskbar and alt-tab screen is expected because the stacks are calling SW_HIDE on whichever windows are not visible, which also hides the window from the taskbar and the alt-tab screen. There is more info on the implementation details of SW_HIDE on this SO thread.

@LGUG2Z commented on GitHub (Nov 15, 2021): > > > It works and you can even drag the new window to the adjacent container! It remembers the focused container even when using the PowerToys launcher btw. I think this is actually undefined behaviour in action which is causing the later issues you describe; I think that when `append-to-container` is enabled, the handler for moving should carry out movements between containers where possible instead of swapping (which is what the handler is doing now). I'll try to work on this in the next days. > > > I'm seeing some odd behavior with windows disappearing (including from the taskbar and alt-tab screen) then re-appearing. I also just saw the two stacks switch positions when closing a window. I'm not sure about the container stack switching, but the windows disappearing from the taskbar and alt-tab screen is expected because the stacks are calling `SW_HIDE` on whichever windows are not visible, which also hides the window from the taskbar and the alt-tab screen. There is more info on the implementation details of `SW_HIDE` [on this SO thread](https://stackoverflow.com/questions/42802403/hide-the-custom-applicaion-window-but-it-should-show-the-application-icon-on-the).

adam commented

@diocletiann commented on GitHub (Nov 15, 2021):

I'm not sure about the container stack switching, but the windows disappearing from the taskbar and alt-tab screen is expected because the stacks are calling SW_HIDE on whichever windows are not visible, which also hides the window from the taskbar and the alt-tab screen. There is more info on the implementation details of SW_HIDE on this SO thread.

What is the benefit of hiding the obscured windows vs just elevating the focused window? The latter would allow for a standard alt-tab and taskbar workflow while still managing the screen space.

@diocletiann commented on GitHub (Nov 15, 2021): > I'm not sure about the container stack switching, but the windows disappearing from the taskbar and alt-tab screen is expected because the stacks are calling `SW_HIDE` on whichever windows are not visible, which also hides the window from the taskbar and the alt-tab screen. There is more info on the implementation details of `SW_HIDE` [on this SO thread](https://stackoverflow.com/questions/42802403/hide-the-custom-applicaion-window-but-it-should-show-the-application-icon-on-the). What is the benefit of hiding the obscured windows vs just elevating the focused window? The latter would allow for a standard alt-tab and taskbar workflow while still managing the screen space.

adam commented

@LGUG2Z commented on GitHub (Nov 15, 2021):

Using SW_HIDE is mostly a result of sticking with the conventions followed by other Windows window managers when I was learning how to work with the Win32 API (nog, workspacer).

The workspaces feature was written first, which made use of the window hiding functionality and it just got reused for the container stack feature.

I think that with some careful refactoring this coupling could be untangled, though the biggest piece of work would be to ensure that the window manager state updates accordingly and consistently when windows are elevated using mechanisms outside of komorebic's CLI commands (alt-tab, clicking on the taskbar etc.)

@LGUG2Z commented on GitHub (Nov 15, 2021): Using `SW_HIDE` is mostly a result of sticking with the conventions followed by other Windows window managers when I was learning how to work with the Win32 API ([nog](https://github.com/TimUntersberger/nog/blob/e318cee5e4b0d9e0520bb207417210026c1d753c/twm/src/system/win.rs#L362), [workspacer](https://github.com/workspacer/workspacer/blob/32783981f22ed2bbf7a32565888b3a27dcf923e7/src/workspacer.Native/Native/WindowsWindow.cs#L177)). The workspaces feature was written first, which made use of the window hiding functionality and it just got reused for the container stack feature. I think that with some careful refactoring this coupling could be untangled, though the biggest piece of work would be to ensure that the window manager state updates accordingly and consistently when windows are elevated using mechanisms outside of komorebic's CLI commands (alt-tab, clicking on the taskbar etc.)

adam commented

@diocletiann commented on GitHub (Nov 15, 2021):

Makes sense, thanks for the context. FWIW, I would gladly give up the "cycle through stack" function to able to use the taskbar and alt-tab through all open windows. I would also trade your "move window" functions for automatic placement of new windows in the "next" stack (so the source doesn't get obscured). That way you're always one alt-tab away from the re-focusing parent and two alt-tabs away from re-surfacing the grandparent.

Thanks for all your efforts!

@diocletiann commented on GitHub (Nov 15, 2021): Makes sense, thanks for the context. FWIW, I would gladly give up the "cycle through stack" function to able to use the taskbar and alt-tab through all open windows. I would also trade your "move window" functions for automatic placement of new windows in the "next" stack (so the source doesn't get obscured). That way you're always one alt-tab away from the re-focusing parent and two alt-tabs away from _re-surfacing_ the grandparent. Thanks for all your efforts!

adam commented

@diocletiann commented on GitHub (Nov 16, 2021):

Just rebuilt the newest commit, dragging into the other container works great. If there was a way to unhide all the open windows so I could alt-tab between them this would be a daily driver. Perhaps "toggle-window-container-behaviour" could also unhide? I don't see why you wouldn't want alt-tab with stacked columns, selecting one then cycling seems tedious and hard to keep track of, especially if the taskbar doesn't help you either.

@diocletiann commented on GitHub (Nov 16, 2021): Just rebuilt the newest commit, dragging into the other container works great. If there was a way to unhide all the open windows so I could alt-tab between them this would be a daily driver. Perhaps "toggle-window-container-behaviour" could also unhide? I don't see why you wouldn't want alt-tab with stacked columns, selecting one then cycling seems tedious and hard to keep track of, especially if the taskbar doesn't help you either.

adam commented

@LGUG2Z commented on GitHub (Nov 19, 2021):

@restfuladi I started working on this and I have pushed what I have done so far to a branch. From my brief testing, it seems that the following two scenarios work once setting window-hiding-behaviour to minimize:

Alt-Tab to access windows on other spaces and auto-switch workspace
Alt-Tab to access windows at a lower layer in the stack and update the wm state accordingly

All: Please feel free to kick the tires on this branch and see if minimizing introduces any unforeseen regressions, especially when transitioning between different layouts and custom layouts.

@LGUG2Z commented on GitHub (Nov 19, 2021): @restfuladi I started working on this and I have pushed what I have done so far to a branch. From my brief testing, it seems that the following two scenarios work once setting `window-hiding-behaviour` to `minimize`: - [x] Alt-Tab to access windows on other spaces and auto-switch workspace - [x] Alt-Tab to access windows at a lower layer in the stack and update the wm state accordingly All: Please feel free to kick the tires on this branch and see if minimizing introduces any unforeseen regressions, especially when transitioning between different layouts and custom layouts.

adam commented

@LGUG2Z commented on GitHub (Nov 20, 2021):

After a few days of usage with window-hiding-behaviour set to minimize by default locally, I think that this is stable enough to be made the default for the upcoming 0.1.7 release so that new users are greeted with more familiar alt-tab behaviour.

@LGUG2Z commented on GitHub (Nov 20, 2021): After a few days of usage with `window-hiding-behaviour` set to `minimize` by default locally, I think that this is stable enough to be made the default for the upcoming `0.1.7` release so that new users are greeted with more familiar alt-tab behaviour.

adam commented

@rollingmoai commented on GitHub (Jan 28, 2022):

Adding these kinds of visual elements to komorebi isn't something that I will be able to work in the near future, but I'm open both to PRs that implement this, and also to people trying to add these kind of visual elements using the new event subscriptions in whatever languages they are comfortable with (maybe something similar to Stackline for yabai).

I haven't tried it yet but you may want to look at FancyWM which does exactly that:

@rollingmoai commented on GitHub (Jan 28, 2022): > Adding these kinds of visual elements to `komorebi` isn't something that I will be able to work in the near future, but I'm open both to PRs that implement this, and also to people trying to add these kind of visual elements using the new [event subscriptions](https://github.com/LGUG2Z/komorebi#window-manager-event-subscriptions) in whatever languages they are comfortable with (maybe something similar to [Stackline](https://github.com/AdamWagner/stackline) for yabai). I haven't tried it yet but you may want to look at [FancyWM](https://www.microsoft.com/en-ph/p/fancywm-dynamic-tiling-window-manager/9p1741lkhqs9) which does exactly that: ![image](https://user-images.githubusercontent.com/75471378/151491240-aaa9d8b3-1b5a-44a2-ab9b-9cd5a06f6494.png)

adam commented

@LGUG2Z commented on GitHub (Jan 28, 2022):

I have seen this and the tabs at the top look very nice! Would love to see the source code for this or any other implementation of custom tabbing on Windows 10+ so that I could learn how to implement something similar myself. 😅

@LGUG2Z commented on GitHub (Jan 28, 2022): I have seen this and the tabs at the top look very nice! Would love to see the source code for this or any other implementation of custom tabbing on Windows 10+ so that I could learn how to implement something similar myself. 😅

adam commented