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

[BUG]: toggle-maximize cannot return to stacked list #448

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

Originally created by @Jaehaks on GitHub (Aug 16, 2024).

Describe the bug
When I restore maximized window to original state which is stacked before it maximizes, It is tiled not stacked.
toggle-monocle did work well, the window which was monocle restore to stack. But toggle-maximize doesn't

To Reproduce
windows_container_behaviour is "Append"

  1. stack some windows over 2, the layout is BSP or VerticalStack.
    left window is single, right window is stacked
  2. toggle-maximize with any window which is stacked in right side
  3. toggle-maximize to restore to original state
  4. the window restores to tiled, not stacked

Expected behavior
it should not be placed in a tile, but should be piled up in the original stack list.

Screenshots and Videos
Add screenshots and videos to help explain your problem.

Operating System

OS Name:                 Microsoft Windows 10 Enterprise
OS Version:                 10.0.19044 N/A build 19044

komorebic check Output

KOMOREBI_CONFIG_HOME detected: C:\Users\USER\.config\Dotfiles\komorebi

Looking for configuration files in C:\Users\USER\.config\Dotfiles\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\USER\.config\Dotfiles\komorebi\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

Additional context
I use whkd instead of ahk

In particular, if you have any other AHK scripts or software running that handle any aspect of window management or manipulation

Originally created by @Jaehaks on GitHub (Aug 16, 2024). **Describe the bug** When I restore maximized window to original state which is stacked before it maximizes, It is tiled not stacked. `toggle-monocle` did work well, the window which was monocle restore to stack. But `toggle-maximize` doesn't **To Reproduce** `windows_container_behaviour` is "Append" 1. stack some windows over 2, the layout is BSP or VerticalStack. left window is single, right window is stacked 2. `toggle-maximize` with any window which is stacked in right side 3. `toggle-maximize` to restore to original state 4. the window restores to tiled, not stacked **Expected behavior** it should not be placed in a tile, but should be piled up in the original stack list. **Screenshots and Videos** Add screenshots and videos to help explain your problem. **Operating System** ``` OS Name: Microsoft Windows 10 Enterprise OS Version: 10.0.19044 N/A build 19044 ``` **`komorebic check` Output** ``` KOMOREBI_CONFIG_HOME detected: C:\Users\USER\.config\Dotfiles\komorebi Looking for configuration files in C:\Users\USER\.config\Dotfiles\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\USER\.config\Dotfiles\komorebi\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ``` **Additional context** I use whkd instead of ahk In particular, if you have any other AHK scripts or software running that handle any aspect of window management or manipulation
adam added the bug label 2026-01-05 14:50:48 +01:00
adam closed this issue 2026-01-05 14:50:48 +01:00
adam commented 2026-01-05 14:50:49 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jan 23, 2025):

This is the expected behavior because in order to maximize a window it must be removed from a container stack and tracking this kind of ephemeral individual window history in the window manager state is not something I'm in favor of.

@LGUG2Z commented on GitHub (Jan 23, 2025): This is the expected behavior because in order to maximize a window it must be removed from a container stack and tracking this kind of ephemeral individual window history in the window manager state is not something I'm in favor of.
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 bug
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#448
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?