OS Name: Microsoft Windows 11 Home
komorebic 0.1.30
branch:feature/reduce-notifications
commit_hash:b3a9c57f
build_time:2024-10-11 17:36:36 +00:00
build_env:rustc 1.81.0 (eeb90cda1 2024-09-04),stable-x86_64-pc-windows-msvc
Should note this occurs on 0.1.28^ as well, or probably every version since komorebic gui was introduced.
Komorebi Configuration
N/A
Hotkey Configuration
N/A
Output of komorebic check
N/A
Originally created by @codyduong on GitHub (Oct 11, 2024).
### Summary
This is probably a to_string() failing (or similar). Works fine in `komorebi log`.
`komorebic gui`

`komorebic log`
```
komorebi::process_event: processed: (hwnd: 7934510, title: Comparing master...feature/reduce-notifications · LGUG2Z/komorebi — Mozilla Firefox, exe: firefox.exe, class: MozillaWindowClass)
```
### Version Information
```
OS Name: Microsoft Windows 11 Home
komorebic 0.1.30
branch:feature/reduce-notifications
commit_hash:b3a9c57f
build_time:2024-10-11 17:36:36 +00:00
build_env:rustc 1.81.0 (eeb90cda1 2024-09-04),stable-x86_64-pc-windows-msvc
```
Should note this occurs on 0.1.28^ as well, or probably every version since komorebic gui was introduced.
### Komorebi Configuration
N/A
### Hotkey Configuration
N/A
### Output of komorebic check
N/A
adam
added the bug label 2026-01-05 14:51:01 +01:00
Right now I think this might be expected behaviour; there are a bunch of early returns here to ensure that we are not wasting CPU cycles trying to further validate a window for management if we already know it has failed early checks.
@LGUG2Z commented on GitHub (Oct 11, 2024):
https://github.com/LGUG2Z/komorebi/blob/7f420423229afabea6de4b2d117474181ccf67ec/komorebi/src/window.rs#L471-L546
Right now I think this might be expected behaviour; there are a bunch of early returns here to ensure that we are not wasting CPU cycles trying to further validate a window for management if we already know it has failed early checks.
In the case of your screenshot, I'm thinking with !allow_cloaked and is_cloaked you hit the (false, true) matcher (under _) and this skipped any title/path/exe lookups.
@LGUG2Z commented on GitHub (Oct 11, 2024):
In the case of your screenshot, I'm thinking with `!allow_cloaked` and `is_cloaked` you hit the `(false, true)` matcher (under `_`) and this skipped any title/path/exe lookups.
Oh, I see. I was using komorebic gui to try and get some .exe names on workspaces not currently visible to float-rule them. Makes sense I guess.
@codyduong commented on GitHub (Oct 11, 2024):
Oh, I see. I was using komorebic gui to try and get some .exe names on workspaces not currently visible to float-rule them. Makes sense I guess.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @codyduong on GitHub (Oct 11, 2024).
Summary
This is probably a to_string() failing (or similar). Works fine in
komorebi log.komorebic guikomorebic logVersion Information
Should note this occurs on 0.1.28^ as well, or probably every version since komorebic gui was introduced.
Komorebi Configuration
N/A
Hotkey Configuration
N/A
Output of komorebic check
N/A
@LGUG2Z commented on GitHub (Oct 11, 2024):
https://github.com/LGUG2Z/komorebi/blob/7f420423229afabea6de4b2d117474181ccf67ec/komorebi/src/window.rs#L471-L546
Right now I think this might be expected behaviour; there are a bunch of early returns here to ensure that we are not wasting CPU cycles trying to further validate a window for management if we already know it has failed early checks.
@LGUG2Z commented on GitHub (Oct 11, 2024):
In the case of your screenshot, I'm thinking with
!allow_cloakedandis_cloakedyou hit the(false, true)matcher (under_) and this skipped any title/path/exe lookups.@codyduong commented on GitHub (Oct 11, 2024):
Oh, I see. I was using komorebic gui to try and get some .exe names on workspaces not currently visible to float-rule them. Makes sense I guess.