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]: Unresponsive/commands queued on heavy load #290

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

Originally created by @melMass on GitHub (Jan 31, 2024).

Describe the bug
Whenever I'm doing some heavy processing (cargo build, AI inference, 3D rendering), komorebi or wkbd is not responding to actions anymore but seems to execute them all at once at some point.

To Reproduce
Steps to reproduce the behavior:

  1. Build a large rust project like nushell
  2. Press the shortcuts to move workspace
  3. See bug

Expected behavior
Some way to make whkb or komorebi "higher" priority somehow?

Screenshots and Videos
I can if needed

Operating System

OS Name:                   Microsoft Windows 11 Professionnel
OS Version:                10.0.22621 N/A Build 22621

komorebic check Output
Not relevant in my case, I run komorebi with args to point to them since env vars did not work (I have the config at ~/.config/komorebi/komorebi.json)

KOMOREBI_CONFIG_HOME detected: C:\Users\User\.config\komorebi

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

No komorebi configuration found in C:\Users\User\.config\komorebi

If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration
Originally created by @melMass on GitHub (Jan 31, 2024). **Describe the bug** Whenever I'm doing some heavy processing (`cargo build`, AI inference, 3D rendering), komorebi or wkbd is not responding to actions anymore but seems to execute them all at once at some point. **To Reproduce** Steps to reproduce the behavior: 1. Build a large rust project like [nushell](https://github.com/nushell/nushell) 2. Press the shortcuts to move workspace 3. See bug **Expected behavior** Some way to make whkb or komorebi "higher" priority somehow? **Screenshots and Videos** I can if needed **Operating System** ``` OS Name: Microsoft Windows 11 Professionnel OS Version: 10.0.22621 N/A Build 22621 ``` **`komorebic check` Output** Not relevant in my case, I run komorebi with args to point to them since env vars did not work (I have the config at ~/.config/komorebi/komorebi.json) ``` KOMOREBI_CONFIG_HOME detected: C:\Users\User\.config\komorebi Looking for configuration files in C:\Users\User\.config\komorebi No komorebi configuration found in C:\Users\User\.config\komorebi If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration ```
adam added the bug label 2026-01-05 14:49:31 +01:00
adam closed this issue 2026-01-05 14:49:31 +01:00
adam commented 2026-01-05 14:49:31 +01:00
Author
Owner
Copy Link

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

You can set the priority in Task Manager for different processes; I would try this.

I've not experienced this myself so I don't really have much to add. If someone wants to debug this (presumably people who can actually reproduce it) I'd suggest figuring out if the issue comes from the OS delaying the sending of events for komorebi to react to, delays in sending/receiving events over named pipes (ie. after komorebic has been invoked), delays in sending commands from the shell opened by whkd (ie. before komorebic invocations can be processed), or something else.

@LGUG2Z commented on GitHub (Feb 8, 2024): You can set the priority in Task Manager for different processes; I would try this. I've not experienced this myself so I don't really have much to add. If someone wants to debug this (presumably people who can actually reproduce it) I'd suggest figuring out if the issue comes from the OS delaying the sending of events for `komorebi` to react to, delays in sending/receiving events over named pipes (ie. after `komorebic` has been invoked), delays in sending commands from the shell opened by `whkd` (ie. before `komorebic` invocations can be processed), or something else.
adam commented 2026-01-05 14:49:31 +01:00
Author
Owner
Copy Link

@melMass commented on GitHub (Feb 8, 2024):

I forgot to report back sorry, after having a few other issues I looked into AHK and switched to it.
Since then it did not happen so If anything it's not a komorebi issue.
Thanks for your work on this project!

@melMass commented on GitHub (Feb 8, 2024): I forgot to report back sorry, after having a few other issues I looked into AHK and switched to it. Since then it did not happen so If anything it's not a komorebi issue. Thanks for your work on this project!
adam commented 2026-01-05 14:49:32 +01:00
Author
Owner
Copy Link

@RaptDept commented on GitHub (Feb 11, 2024):

You can set the priority in Task Manager for different processes; I would try this.

Setting komorebi and whkd to Normal definitely helped me. I noticed that they both run as Below Normal priority by default, and I get the same problem as OP when the system is under load even from an automated background task like Search Indexer, which can be frustrating.

If someone wants to debug this (presumably people who can actually reproduce it) I'd suggest figuring out if the issue comes from the OS delaying the sending of events for komorebi to react to, delays in sending/receiving events over named pipes (ie. after komorebic has been invoked), delays in sending commands from the shell opened by whkd (ie. before komorebic invocations can be processed), or something else.

I'd like to help (I use whkd with komorebi), but I'm not quite sure how to isolate where the delay is coming from.

However, wouldn't it make sense to just let komorebi and whkd run on Normal priority by default? I would argue that both shouldn't be treated as below normal priority "background" tasks since whkd deals with global user input while komorebi augments the operating system's GUI, and I think both of those things should be responsive.

@RaptDept commented on GitHub (Feb 11, 2024): > You can set the priority in Task Manager for different processes; I would try this. Setting komorebi and whkd to Normal definitely helped me. I noticed that they both run as Below Normal priority by default, and I get the same problem as OP when the system is under load even from an automated background task like Search Indexer, which can be frustrating. > If someone wants to debug this (presumably people who can actually reproduce it) I'd suggest figuring out if the issue comes from the OS delaying the sending of events for `komorebi` to react to, delays in sending/receiving events over named pipes (ie. after `komorebic` has been invoked), delays in sending commands from the shell opened by `whkd` (ie. before `komorebic` invocations can be processed), or something else. I'd like to help (I use whkd with komorebi), but I'm not quite sure how to isolate where the delay is coming from. However, wouldn't it make sense to just let komorebi and whkd run on Normal priority by default? I would argue that both shouldn't be treated as below normal priority "background" tasks since whkd deals with global user input while komorebi augments the operating system's GUI, and I think both of those things should be responsive.
adam commented 2026-01-05 14:49:32 +01:00
Author
Owner
Copy Link

@RaptDept commented on GitHub (Feb 11, 2024):

Never mind, I've been using Task Scheduler to run both of them and I just learned that processes started with Task Scheduler run on Below Normal priority by default. My bad.

@RaptDept commented on GitHub (Feb 11, 2024): Never mind, I've been using Task Scheduler to run both of them and I just learned that processes started with Task Scheduler run on Below Normal priority by default. My bad.
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#290
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?