[BUG]: Unresponsive/commands queued on heavy load #290

New Issue

2026-01-05T14:49:31+01:00

adam commented

2026-01-05 14:49:31 +01:00

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:

Build a large rust project like nushell
Press the shortcuts to move workspace
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

@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

@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

@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

@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.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#290