mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: Win 10 2 Monitors Resize problem #365
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 @Ashikaga1974 on GitHub (May 6, 2024).
Describe the bug
First of all, sorry for my bad english.
I'll try to explain:
I have a Win 10 Prof LTSE Setup with the latest komorebi installed with
2 Monitors.
On Monitor 1 (my primary monitor) i open 2 windows on default workspace in default layout.
1 of the windows i switch to fullscreen with the 3 windows buttons. Then i left the Monitor
to the right monitor with my mouse, after that i go back to my primary monitor, with my mouse.
The fully-sized window will automaticly rearrange to tiling.
.JSON:
{
"$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.24/schema.json",
"app_specific_configuration_path": "$Env:USERPROFILE/applications.yaml",
"window_hiding_behaviour": "Cloak",
"cross_monitor_move_behaviour": "Insert",
"default_workspace_padding": 3,
"default_container_padding": 3,
"border_padding": 5,
"border_offset": -1,
"focus_follows_mouse": "Windows",
"active_window_border": true,
"active_window_border_style": "Rounded",
"active_window_border_width": 3,
"active_window_border_colours": {
"single": "#42a5f5",
"stack": "#00a542",
"monocle": "#ff3399"
},
"monitors": [
{
"workspaces": [
{
"name": "I",
"layout": "BSP"
},
{
"name": "II",
"layout": "VerticalStack"
},
{
"name": "III",
"layout": "HorizontalStack"
},
{
"name": "IV",
"layout": "UltrawideVerticalStack"
},
{
"name": "V",
"layout": "Rows"
}
]
}
]
}
To Reproduce
Steps to reproduce the behavior:
Lets have a look at my dscription :)
Expected behavior
The full size window on monitor 1 continues to display at full size :)
Screenshots and Videos
I can record a video, if needed :)
Operating System
Win 10 Prof. LTSE
komorebic checkOutputI can do a output, if needed :)
@Ashikaga1974 commented on GitHub (May 7, 2024):
Video :)
Hope this helps.
https://github.com/LGUG2Z/komorebi/assets/110775164/be35cca6-a401-4eb4-a139-f4062bf6139c
@Ashikaga1974 commented on GitHub (May 7, 2024):
Additional information:
It's a problem of the property: "focus_follows_mouse": "Windows"
This property causes the problem on windows 10.
After deleting the property, everything is ok.
But it's still a bug, i think.
@Ashikaga1974 commented on GitHub (May 7, 2024):
The tiling is still there, when the fully-sized window gets the focus on mouse-click
@LGUG2Z commented on GitHub (May 7, 2024):
Does this also happen when you use the "toggle-fullscreen" komorebic command instead of the maximize button? 🤔
@Ashikaga1974 commented on GitHub (May 7, 2024):
No, this seems to work.
Manipulate windows
alt + t : komorebic toggle-maximize
@LGUG2Z commented on GitHub (May 8, 2024):
I don't think we are tracking events sent from the window buttons; I'll leave this issue open in case someone wants to implement it, but generally I recommend using the komorebic commands because they ensure that the internal state will always be updated and avoid issues like these
@Ashikaga1974 commented on GitHub (May 8, 2024):
I recommend using the Windows Buttons cause they are Standard Windows Feature! Sorry!
@LGUG2Z commented on GitHub (May 8, 2024):
I remember now why this hasn't been implemented: because Microsoft doesn't let developers get notified when a Window is maximized using the button: https://learn.microsoft.com/en-us/windows/win32/winauto/event-constants
I don't think there is much to do here until Microsoft provides WinEvents for window maximization for developers. Just like the discussion around Windows Virtual Desktops, this is a feature request for the Multi Billion Dollar Company ™️
@Ashikaga1974 commented on GitHub (May 10, 2024):
Unfortunately not. Winuser.h is also applied in Windows 11. As soon as komorebi is started, such errors occur in Windows 10 systems, so it can be assumed that komorebi is consuming something wrong there. On Windows 11 systems, you don't have to struggle with the problem.
@LGUG2Z commented on GitHub (May 10, 2024):
There is no simply event to consume to be acted on; in this case Microsoft changed something unspecified and undocumented between Win 10 and Win 11 which results in the different behaviour experienced here