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]: workspace padding and container padding is inconsistent before/after retile #153

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

Originally created by @maxbane on GitHub (Oct 21, 2022).

Describe the bug
When komorebi first starts up, the padding between windows (i.e. between each other) and between windows and monitor edges seems "too large" to me (I've configured smaller padding than default). komorebic retile causes the padding to shrink a lot (more like what I want), but this seems like a bug. Which padding is correct? Before the retile or after the retile?

See screencap video below for a demonstration.

To Reproduce
Snippet from my komorebi.ahk:

; Lower monitor
WorkspaceLayout(1, 0, "bsp")
WorkspacePadding(1, 0, 3)
ContainerPadding(1, 0, 5)

; Uncomment the next two lines if you want a visual border drawn around the focused window
ActiveWindowBorderColour(68, 71, 90, "single") ; Dracula "selection" color

My intention is for the padding between windows (and monitor edges) to be about the same as the thickness of the active window border. But I find that the configuration above gives different actual padding amounts depending on whether komorebi has just started up, or whether a retile or configuration-reload has occurred.

Expected behavior
The amount of padding should presumably be the same at start-up as after retile/reload.

Screenshots and Videos
Demonstration video: https://imgur.com/a/bPiQRjb

Operating System

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19044 N/A Build 19044
Originally created by @maxbane on GitHub (Oct 21, 2022). **Describe the bug** When komorebi first starts up, the padding between windows (i.e. between each other) and between windows and monitor edges seems "too large" to me (I've configured smaller padding than default). `komorebic retile` causes the padding to shrink a lot (more like what I want), but this seems like a bug. Which padding is correct? Before the retile or after the retile? See screencap video below for a demonstration. **To Reproduce** Snippet from my `komorebi.ahk`: ``` ; Lower monitor WorkspaceLayout(1, 0, "bsp") WorkspacePadding(1, 0, 3) ContainerPadding(1, 0, 5) ; Uncomment the next two lines if you want a visual border drawn around the focused window ActiveWindowBorderColour(68, 71, 90, "single") ; Dracula "selection" color ``` My intention is for the padding between windows (and monitor edges) to be about the same as the thickness of the active window border. But I find that the configuration above gives different actual padding amounts depending on whether komorebi has just started up, or whether a retile or configuration-reload has occurred. **Expected behavior** The amount of padding should presumably be the same at start-up as after retile/reload. **Screenshots and Videos** Demonstration video: https://imgur.com/a/bPiQRjb **Operating System** ``` OS Name: Microsoft Windows 10 Pro OS Version: 10.0.19044 N/A Build 19044 ```
adam added the bug label 2026-01-05 14:48:35 +01:00
adam closed this issue 2026-01-05 14:48:35 +01:00
adam commented 2026-01-05 14:48:35 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 21, 2022):

Definitely looks a little weird; can you try starting with the --await-configuration flag and see if the same behaviour persists? I have a feeling that the configuration option initially gets sent after the initial layout has taken place; with --await-configuration the first layout should not happen until all commands have been sent.

@LGUG2Z commented on GitHub (Oct 21, 2022): Definitely looks a little weird; can you try starting with the [`--await-configuration` flag](https://github.com/LGUG2Z/komorebi#multiple-layout-changes-on-startup) and see if the same behaviour persists? I have a feeling that the configuration option initially gets sent after the initial layout has taken place; with `--await-configuration` the first layout should not happen until all commands have been sent.
adam commented 2026-01-05 14:48:35 +01:00
Author
Owner
Copy Link

@maxbane commented on GitHub (Oct 22, 2022):

Interesting, yeah, I think that's what's happening, but the fix is tricky. Even with --await-configuration the behavior would sometimes persist and sometimes not. I finally realized from the logs that it's because the order in which the configuration commands are processed is not deterministic, and not necessarily the order in which they appear in komorebi.ahk. I would often see that CompleteConfiguration got processed before ContainerPadding was processed, even though CompleteConfiguration is last in the config file.

It's because komorebic.lib.ahk uses Run for all of its komorebic.exe calls. This is asynchronous and doesn't guarantee that a sequence of calls will finish in a particular order... all of the komorebic.exe processes get forked in the background and run in parallel.

Replacing all the usages of Run with RunWait in komorebic.lib.ahk fixed the behavior, and it doesn't seem to be any slower.

Maybe consider generating komorebic.lib.ahk with RunWait instead of Run? I think it might be the only way to ensure that configuration commands get processed in their order of appearance in the config file, which is probably what the user expects.

@maxbane commented on GitHub (Oct 22, 2022): Interesting, yeah, I think that's what's happening, but the fix is tricky. Even with `--await-configuration` the behavior would sometimes persist and sometimes not. I finally realized from the logs that it's because the order in which the configuration commands are processed is not deterministic, and not necessarily the order in which they appear in `komorebi.ahk`. I would often see that `CompleteConfiguration` got processed before `ContainerPadding` was processed, even though `CompleteConfiguration` is last in the config file. It's because `komorebic.lib.ahk` uses `Run` for all of its `komorebic.exe` calls. This is asynchronous and doesn't guarantee that a sequence of calls will finish in a particular order... all of the `komorebic.exe` processes get forked in the background and run in parallel. Replacing all the usages of `Run` with `RunWait` in `komorebic.lib.ahk` fixed the behavior, and it doesn't seem to be any slower. Maybe consider generating `komorebic.lib.ahk` with `RunWait` instead of `Run`? I think it might be the only way to ensure that configuration commands get processed in their order of appearance in the config file, which is probably what the user expects.
adam commented 2026-01-05 14:48:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 22, 2022):

Good catch, I didn't realise that Run was an async command. I've updated the library generation command and the example library and the generated file at the root of the repo. You should be able to run iwr https://raw.githubusercontent.com/LGUG2Z/komorebi/master/komorebic.lib.ahk -OutFile $Env:USERPROFILE\komorebic.lib.ahk to grab the latest and try again.

@LGUG2Z commented on GitHub (Oct 22, 2022): Good catch, I didn't realise that `Run` was an async command. I've updated the library generation command and the example library and [the generated file at the root of the repo](https://github.com/LGUG2Z/komorebi/blob/1229c655808f0cd69e665f4778c3d9a178b947e2/komorebic.lib.ahk). You should be able to run `iwr https://raw.githubusercontent.com/LGUG2Z/komorebi/master/komorebic.lib.ahk -OutFile $Env:USERPROFILE\komorebic.lib.ahk` to grab the latest and try again.
adam commented 2026-01-05 14:48:36 +01:00
Author
Owner
Copy Link

@maxbane commented on GitHub (Oct 24, 2022):

Cool, thanks! I'll call this closed 👍🏻

@maxbane commented on GitHub (Oct 24, 2022): Cool, thanks! I'll call this closed 👍🏻
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#153
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?