mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: toggle-maximize on non tiling workspaces is broken #607
Reference in New Issue
Block a user
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?
Originally created by @CaMeLCaseError on GitHub (Apr 30, 2025).
Summary
how to reprodue:
make all workspaces "non tiling" by removing the layout description in komorebi.json
use toggle-maximize on an unmaximized window: gets maximized
use toggle-maximize in the maximized window: nothing happens.
also various other bugs/weird behaviors happen if you switch between multiple maximized and non maximized windows on the same workspace e.g. by using the mouse. Sometimes the toggle-maximize is ignored completely (using toggle-maximize for 10 times does nothing), then selecting a different window using the mouse and switching back to the first window makes maximizing possibe again. Unmaximizing never works using the toggle.
The state for "maximized" and "unmaximized" seems still to be remembered. Only every odd toggle is successful. Even toggles that are meant for unmaximizing do nothing.
Version Information
windows11
ahk v2
komorebi 0.1.36
tag:v0.1.36
commit_hash:8ef1bcf2
build_time:2025-04-13 03:10:57 +00:00
build_env:rustc 1.86.0 (05f9846f8 2025-03-31),stable-x86_64-pc-windows-msvc
Komorebi Configuration
Hotkey Configuration
#Requires AutoHotkey v2.0.2
#SingleInstance Force
F12::Browser_Forward
; Helper function to run komorebic commands
Komorebic(cmd) {
RunWait(format("komorebic.exe {}", cmd), , "Hide")
}
; Define function to toggle tiling
ToggleTiling() {
stateFilePath := "C:/Users/Martin/tiling_state.txt"
}
; Map RWin + Number to focus workspace
RWin & 1::Komorebic("focus-workspace 0")
RWin & 2::Komorebic("focus-workspace 1")
RWin & 3::Komorebic("focus-workspace 2")
RWin & q::Komorebic("focus-workspace 3")
RWin & w::Komorebic("focus-workspace 4")
RWin & r::ToggleTiling() ; Map RWin + R back to ToggleTiling
;RWin & r::MsgBox("Hotkey triggered")
RWin & t::Komorebic("retile")
RWin & Tab::Komorebic("toggle-maximize")
; Full screen toggle?
; Add more mappings for RWin & 5, 6, 7, 8 if needed
; Map LAlt + RWin + Number to move window to workspace
#HotIf GetKeyState("LAlt", "P")
RWin & 1::Komorebic("move-to-workspace 0")
RWin & 2::Komorebic("move-to-workspace 1")
RWin & 3::Komorebic("move-to-workspace 2")
RWin & q::Komorebic("focus-workspace 3")
RWin & w::Komorebic("move-to-workspace 4")
RWin & c::Komorebic("close")
Output of komorebic check
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Martin
Looking for configuration files in C:\Users\Martin
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\Martin.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
@LGUG2Z commented on GitHub (Apr 30, 2025):
Responding just to the title: this is somewhat expected undefined behaviour - on a non-tiling workspace there are no guarantees about what calling commands designed for tiling workspaces will do
@LGUG2Z commented on GitHub (Apr 30, 2025):
There are no plans to attempt to support maximization by mouse until Microsoft updates the Win32 API surface to provide developers with a way to listen to maximization/unmaximization events
@CaMeLCaseError commented on GitHub (May 1, 2025):
Thanks for the super fast reply :) and Thanks for Komorebi! I'm coming from a multi desktop, non tiling linux WM (XFCE4) and am really happy about Komorebi giving me multiple desktops and useful multi monitor support (xfce4 is lacking good multi monitor support actually).
I'm just not getting used to tiling in all situations yet and also maybe never will for certain tasks.
I saw other tiling WMs do sometims support floating windows so I thought there might be a way in Komorebi as well. And it's funny (not amusingly) that an OS that can not deal with windows is called "Windows" ;) I'd love to not try an other new WM and stick with Komorebi. :) So for me that's a big feature request to support a floating workspace "layout" among all the tiling layouts :)
@CaMeLCaseError commented on GitHub (May 1, 2025):
I'd be happy about completely mouse-free maximizing and unmaximizing. I was just using the mouse because the keyboard didn't do anything useful :)
@LGUG2Z commented on GitHub (May 1, 2025):
From what it sounds like it's possible to do most of what you're looking for - you can have tiling workspaces with "float_override" set to true, and that will float every window spawned on a tiling workspace, and of course you can also toggle on a case by case basis with
toggle-floatYour best bet for this kind of "getting started and figuring out a workflow that works for me" support is to drop by the Discord and open a thread in the #support forum
As for this ticket, I think the main action item to take here is to ensure that toggles via
komorebiccommands are generally not initiated on non-tiling workspaces to clearly communicate "this isn't a valid action on a non-tiling workspace"@mosamadeeb commented on GitHub (Sep 19, 2025):
That sounds like a good solution, I also was confused when maximize didn't toggle off.
I am not sure if this is in-scope for komorebi, but perhaps a different toggle/config could allow normal maximizing instead? that would work regardless if it's tiled or not, similar to how GlazeWM allows it being configured. I remember I had that enabled and maximizing worked exactly the same as the native maximize button (i don't know how it works though).
At least this could be used in non-tiled workspaces, then it wouldn't really matter if komorebi knows when windows are maximized/unmaximized.