Afair it was working fine in actual virtual desktops by actualtools.
Originally created by @pigmej on GitHub (Oct 21, 2021).
Originally assigned to: @LGUG2Z on GitHub.
Let's say that you use WSL2 & x410 combo in windowed apps mode. Then window will be created in a form of:
```
Untitled File 1 - gedit
ahk_class X410_XAppWin
ahk_exe X410.exe
ahk_pid 1456
```
Currently, that window seems to be completely unmanaged by komorebi. I was wondering if it's possible to manage it.
It works with "normal" window snap to XYZ thingy. x410 docu about it states: https://x410.dev/news/want-to-snap-gnome-apps-to-your-screen-edges-like-windows-apps-get-the-new-x410-version-2-9-3/
Afair it was working fine in `actual virtual desktops` by actualtools.
Can you run the AHK script below and share the WindowStyle and WindowExStyle output for a x410 app? This will help me narrow down why it is being excluded by the current window management logic.
@LGUG2Z commented on GitHub (Oct 21, 2021):
Can you run the AHK script below and share the WindowStyle and WindowExStyle output for a x410 app? This will help me narrow down why it is being excluded by the current window management logic.
https://www.computoredge.com/AutoHotkey/Downloads/CheckStyles.ahk
The diff with x410 and wslg is that x410 "can snap" to standard windows snap thingy (also fancy zones), while wslg cannot. Not sure how big diff that makes for komorebi though.
@pigmej commented on GitHub (Oct 21, 2021):
The diff with x410 and wslg is that x410 "can snap" to standard windows snap thingy (also fancy zones), while wslg cannot. Not sure how big diff that makes for komorebi though.
Something changed in the behavior, My X410 windows now have following properties:
check the last two from the second screen.
@pigmej commented on GitHub (Oct 29, 2021):
Hey @LGUG2Z,
Something changed in the behavior, My X410 windows now have following properties:
<img width="491" alt="2021-10-29_09-08_1" src="https://user-images.githubusercontent.com/496754/139391386-8cc54e72-c5cf-4321-82c2-bb48163707d3.png">
<img width="489" alt="2021-10-29_09-08" src="https://user-images.githubusercontent.com/496754/139391384-7a29838b-17d0-4d99-b7ec-a33466725707.png">
check the last two from the second screen.
In this case I think instead of trying to play catch up with X410 the best approach will be to add a managed override for windows spawned by that exe:
komorebicmanage-ruleexeX410.exe
@LGUG2Z commented on GitHub (Oct 29, 2021):
In this case I think instead of trying to play catch up with X410 the best approach will be to add a managed override for windows spawned by that exe:
```powershell
komorebic manage-rule exe X410.exe
```
@LGUG2Z I think there is sth fishy going on. I just noticed that these windows are "unmanaged" when they're first spawned, but all that I have to do is minimize and bring it back again then it's fine.
Does that happen to you too?
I haven't found any diffs for window style what so ever after minimize action. It seems that it's some W11 awkwardness or sth.
@pigmej commented on GitHub (Oct 30, 2021):
@LGUG2Z I think there is sth fishy going on. I just noticed that these windows are "unmanaged" when they're first spawned, but all that I have to do is minimize and bring it back again then it's fine.
Does that happen to you too?
I haven't found any diffs for window style what so ever after minimize action. It seems that it's some W11 awkwardness or sth.
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 @pigmej on GitHub (Oct 21, 2021).
Originally assigned to: @LGUG2Z on GitHub.
Let's say that you use WSL2 & x410 combo in windowed apps mode. Then window will be created in a form of:
Currently, that window seems to be completely unmanaged by komorebi. I was wondering if it's possible to manage it.
It works with "normal" window snap to XYZ thingy. x410 docu about it states: https://x410.dev/news/want-to-snap-gnome-apps-to-your-screen-edges-like-windows-apps-get-the-new-x410-version-2-9-3/
Afair it was working fine in
actual virtual desktopsby actualtools.@LGUG2Z commented on GitHub (Oct 21, 2021):
Can you run the AHK script below and share the WindowStyle and WindowExStyle output for a x410 app? This will help me narrow down why it is being excluded by the current window management logic.
https://www.computoredge.com/AutoHotkey/Downloads/CheckStyles.ahk
@pigmej commented on GitHub (Oct 21, 2021):
Do you still want them after I shared the stuff in #53 ?
@LGUG2Z commented on GitHub (Oct 21, 2021):
Yes please, just curious to know if this behaviour is the same across all of the WSL UI solutions. 🤔
@pigmej commented on GitHub (Oct 21, 2021):
Both from X410 included.


@pigmej commented on GitHub (Oct 21, 2021):
The diff with x410 and wslg is that x410 "can snap" to standard windows snap thingy (also fancy zones), while wslg cannot. Not sure how big diff that makes for komorebi though.
@pigmej commented on GitHub (Oct 22, 2021):
Works good! :)
@pigmej commented on GitHub (Oct 29, 2021):
Hey @LGUG2Z,
Something changed in the behavior, My X410 windows now have following properties:
check the last two from the second screen.
@LGUG2Z commented on GitHub (Oct 29, 2021):
In this case I think instead of trying to play catch up with X410 the best approach will be to add a managed override for windows spawned by that exe:
@pigmej commented on GitHub (Oct 30, 2021):
@LGUG2Z I think there is sth fishy going on. I just noticed that these windows are "unmanaged" when they're first spawned, but all that I have to do is minimize and bring it back again then it's fine.
Does that happen to you too?
I haven't found any diffs for window style what so ever after minimize action. It seems that it's some W11 awkwardness or sth.