mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Manage rules and tray settings do not work for certain application #71
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 @JSamir on GitHub (Jan 5, 2022).
Originally assigned to: @LGUG2Z on GitHub.
Hi,
thanks for this great project, which made me finally enjoy windows :)
I've got this application which is always started on my working laptop and resides in the system tray.
First weird thing was, that this app appeared as a tile when starting komorebi, although I did never open it. Whats even more confusing: if I open the same application from the tray icon, I see some other window (other contents). But the window that komorebi starts managing, I've never seen it.
First I tried to apply the float-rule for this Window via title, exe and class (by using ahk spy), it did not work. Then I tried to specify this is a app that closes to tray, but that did not help either.
The only thing I noticed is that this window which gets tiled, it only has the "close" (x) icon at the top right (and the icon does look a bit different then normal windows close/minimize/maximize icons). Other then that, the class also looks unusual:
WindowsForms10.Window.8.app.0.878ded_r6_ad1Do you have an idea why this is happening?
@LGUG2Z commented on GitHub (Jan 7, 2022):
If I understand correctly, it seems like you have a "blank" tile that is taking up space on the screen? Can you share the output of
komorebic statewhen this happens on your screen?@JSamir commented on GitHub (Jan 10, 2022):
That is partly correct.
When I first start komorebi, this app (or a window of this app) is shown in a tile, just like any other window. Which should not be the case because I specified that a window with this class/exe/title should not be tiled.
After I close this window with X, it is taking up the space in this tile, but the tile looks empty. So yes, at this point the tile looks blank.
If I search for this app in the task manager and kill the process, the empty tile is gone.
Here is the output of
komorebic stateafter I clicked on X in the window (having the blank tile),ERIS_UIbeing the app in question:@LGUG2Z commented on GitHub (Jan 10, 2022):
Thanks for sharing the output! Can you share the relevant lines that you are using in your config to try and exclude this window from tiling?
Also, can you try running the following command against the window when it is still visible and focused?
I would be interested to see if running that explicitly removes the window from layout calculations.
@JSamir commented on GitHub (Jan 10, 2022):
I have tried all of the three mentioned ways:
Also
identify-tray-applicationandidentify-border-overflow.I have bound
unmanageto a shortcut and used it while this window was active, nothing changed unfortunately.@LGUG2Z commented on GitHub (Jan 11, 2022):
Definitely very strange behaviour. I have pushed a commit to this branch which adds a debug statement every time a window is approved for management by
komorebi.Can you try running this with the following command (to suppress most other logging output and just show the debug statement):
$env:RUST_LOG = 'warn'; komorebi(or$env:RUST_LOG = 'warn'; cargo run --bin komorebiif you check out the branch yourself and build it).The float rules are always the first thing checked when deciding if a window should be managed or not, so if this application is getting past there and ends up being managed, the debug statement will show the class, title and exe that
komorebiis seeing for this application at runtime.@LGUG2Z commented on GitHub (Jan 13, 2022):
@JSamir Any updates on this?
@JSamir commented on GitHub (Jan 14, 2022):
Sorry for the delay, here is the output:
It looks like Title/Class/Exe matches what I have in my floating rules:
@LGUG2Z commented on GitHub (Jan 14, 2022):
Thanks for taking the time to do this. I have just pushed another commit to the same branch that adds more debug statements around the float rule comparisons:
There may be an an issue with how the list of float rule identifiers is being stored in and accessed with a Mutex. hopefully this will give us a direct look at what is being stored there and the comparisons being made 🤞 .
@JSamir commented on GitHub (Jan 15, 2022):
First time I start the app, the output shows a list of
float_identifierswhich I would not expect. I noticed that after I click on some other window (e.g. VSCode to paste the output in there), the output that is generated after this action does contain the expected list.Therefore I'll first paste the output which comes after I execute the app an nothing else:
This is all of the output, including the above, where I only clicked to VSCode and back to powershell window:
@JSamir commented on GitHub (Jan 15, 2022):
This is the output of starting the app in powershell and then closing "that" app via click on X and going back to powershell for copypaste. Closing "that" app did not make the tile disappear, just the app (so nothing has changed).
@LGUG2Z commented on GitHub (Jan 15, 2022):
From these logs, it seems that ERIS_UI.exe is being started before the
float_identifiershave been populated with user options via the CLI (which makes sense because user options are not loaded at startup but once the komorebic connection socket has been opened), and so it gets managed as a regular Window.I will try to recreate this with some apps on my computer. If this is the case, I think that we can ensure that managed windows which match a new float rule are removed from the state when the
komorebic float-rulecommand is processed. 🤞I will try to spend some time on this in the next couple of days.
@LGUG2Z commented on GitHub (Jan 15, 2022):
I was able to recreate this issue to an extent, though after closing the window of the offending application, the layout was updated. I pushed another commit on the same branch to purge any windows that match any new float rules from the visible workspace on every connected monitor; let me know how this works out for that
ERIS_UI.exe.@JSamir commented on GitHub (Jan 17, 2022):
With this patch, when first starting komorebi I can see the offending window for a second and then it's gone. So I do not need to close it myself.
It's unfortunate that it can be seen for a second, but for me not an issue since I won't see it again for that session.
So for me with this patch the issue is resolved.
@LGUG2Z commented on GitHub (Jan 17, 2022):
Glad this has resolved the issue. I will merge this to the master branch and make sure it is included in the next release.