Closed RamonUnch closed 2 weeks ago
I was looking at the codebase earlier and I was thinking that if the last event emitted by AltSnap for either move or drag was EVENT_SYSTEM_MOVESIZEEND
komorebi would probably just handle that event as expected 🤔
I guess it would work for AltSnap but Native movement does not always send this message, it is usually just sends WM_MOVE
, WM_WINDOWPOSCHANGING
and WM_WINDOWPOSCHANGED
, but for each mouse event (continuously) so it would have to be in addition to the click event.
I agree however that using the EVENT_SYSTEM_MOVESIZEEND
event would be the simplest and it would not require any work from my side.
Also it should help some other users because this message is sent when you use the the system menu option to move the window (needed when you have no mouse). For now komorebi does not handle this situation and ignores movements that were made via the system menu option.
TIL about system menu move!
I just tried doing this on an Edge window, selecting both "move" and "size" (separately) with the keyboard, moving around and then hitting Return:
2024-05-13T23:52:43.645882Z INFO process_event{event=MoveResizeStart(SystemMoveSizeStart, Window { hwnd: 859142 })}: komorebi::process_event: processed: (hwnd: 859142, title: New tab - Profile 1 - Microsoft​ Edge, exe: msedge.exe, class: Chrome_WidgetWin_1)
2024-05-13T23:52:53.717188Z INFO process_event{event=MoveResizeEnd(SystemMoveSizeEnd, Window { hwnd: 859142 })}: komorebi::process_event: processed: (hwnd: 859142, title: New tab - Profile 1 - Microsoft​ Edge, exe: msedge.exe, class: Chrome_WidgetWin_1)
When I began moving with the keyboard after selecting both of these, EVENT_SYSTEM_MOVESIZESTART
was triggered, and when I hit Return EVENT_SYSTEM_MOVESIZEEND
was triggered.
In the case of the "size" option, hitting return did in fact trigger komorebi's resize logic!
The "move" option however does not trigger a move in komorebi (or rather, a container swap), because the determination of which container to swap with is made by the final cursor position when EVENT_SYSTEM_MOVESIZEEND
is received.
This is good news, even it it does not work with the system menu's move it means it should work together with AltSnap now. I am sure some people will appreciate.
Status still open? Working/not yet?
@aspauldingcode
Status still open? Working/not yet?
It sounds like just AltSnap would have to be updated for Komorebi to respect window resizing/moving. Not sure if this will be addressed next release.
For now I threw together a (messy) solution in my komorebi.ahk
script to resize and move windows via the System Menu (Alt+Space would be the default bind. It's delightfully janky and not as clean/pretty/worry-free as AltSnap but it does let me move/resize windows without having to move my hand off the mouse or strain my wrist to grab the title bar or window border. I find that if you use it slowly it does a little better.
I definitely intend to switch 100% back to AltSnap next release if it works with Komorebi but this is what I have to hold me over till then. I'm happy to consider suggested alternatives to this method.
Lo and behold, here's a video demonstration followed by what I have inserted into my komorebi.ahk
script (and here's a repo with my komorebei.json and komorebi.ahk. You can either incorporate this into your komorebi.ahk script or run it as a standalone script. If AltSnap is running, it will prevent this script from working if there's a conflict with the hotkeys.
https://github.com/user-attachments/assets/881e7fc9-f7e3-40cc-98a2-b107a9936f8b
#Requires AutoHotkey v2.0.2
#SingleInstance Force
~Home:: ; Doubletapping Home will reload the script. {{{
{
if (A_PriorHotkey != "~Home" or A_TimeSincePriorHotkey > 400)
{
; Too much time between presses, so this isn't a double-press.
KeyWait "Home"
return
}
Reload
}
; Resize with mouse
#RButton:: ; Should be safe to change the modifier key as desired
{
MouseGetPos , , &WindowID
Winactivate(WindowID)
ResizeWindow()
KeyWait "RButton"
Send "{LButton}"
}
#LButton::
{
MouseGetPos , , &WindowID
Winactivate(WindowID)
WM_SYSCOMMAND := 0x0112 ; This is a cleaner way to invoke the System Menu
SC_MOVE := 0xF010 ; than sending an Alt+Space followed by m.
PostMessage WM_SYSCOMMAND, SC_MOVE, 0, , "A" ; I like it.
Send "{Down}"
Keywait "LButton"
Send "{LButton}"
}
ResizeWindow() ; A little sum sum to hold us over until AltSnap is updated to work alongside Komorebi
{
CoordMode "Mouse", "Window"
MouseGetPos &CursorPinX, &CursorPinY, &WindowID
WinGetPos &WindowPinX, &WindowPinY, &WindowWidth, &WindowHeight, WindowID
Threshold := 0.25
MouseRelX := CursorPinX / WindowWidth
MouseRelY := CursorPinY / WindowHeight
; Note that WinGetPos returns the coordinates of the top-left corner of the specified window
Left := ( ( CursorPinX ) / WindowWidth ) < ( Threshold )
Right := ( ( CursorPinX ) / WindowWidth ) > ( 1.00 - Threshold )
Top := ( ( CursorPinY ) / WindowHeight ) < ( Threshold )
Bottom := ( ( CursorPinY ) / WindowHeight ) > ( 1.00 - Threshold )
WM_SYSCOMMAND := 0x0112 ; This is a cleaner way to invoke the System Menu
SC_SIZE := 0xF000 ; than sending an Alt+Space followed by s.
PostMessage WM_SYSCOMMAND, SC_SIZE, 0, , "A" ; I like it.
If Left
{
Send "{Left}"
}
If Right
{
Send "{Right}"
}
If Top
{
Send "{Up}"
}
If Bottom
{
Send "{Down}"
}
}
here's a video demonstration followed by what I have inserted into my komorebi.ahk script
Dang that's actually really close. Nice script!
It is so cool!! I have disabled my altsnap!
I agree however that using the EVENT_SYSTEM_MOVESIZEEND event would be the simplest and it would not require any work from my side.
This is good news, even it it does not work with the system menu's move it means it should work together with AltSnap now. I am sure some people will appreciate.
@RamonUnch It seems to me from these answers that you think that this is solved on komorebi side. But it is not. Komorebi was already checking for the events EVENT_SYSTEM_MOVESIZESTART
and EVENT_SYSTEM_MOVESIZEEND
when this issue was opened.
The problem is that when AltSnap moves a window it sends the WM_ENTERSIZEMOVE
on start and WM_EXITSIZEMOVE
when it finishes the movement to the window that is being moved. However the moved window or AltSnap never produce EVENT_SYSTEM_MOVESIZESTART
and EVENT_SYSTEM_MOVESIZEEND
so komorebi has no way to know about the move that just happened.
From what I understand the EVENT_SYSTEM...
messages should be produced by the system. I don't know if there is a way for AltSnap to produce those messages for the window that is being moved?
Can you please have another look at this?
I've made a PR to try to fix this. #564
If anyone could test it it and give me some feedback to make sure it doesn't break anything it would be great!
PR works fantastically, thank you so much @alex-ds13 ! Sometimes resizing a window doesn't work (or doesn't work in one dimension when resizing a corner), but I get that with regular Komorebi sometimes so I don't think it's an issue with your fork.
Tested on Windows 10 Education 22H2 19045.5011 and built using GCC 14.1.0 (MSYS2)
I've made a PR to try to fix this. #564
If anyone could test it it and give me some feedback to make sure it doesn't break anything it would be great!
Thanks for your effort!!
I've made a PR to try to fix this. #564
If anyone could test it it and give me some feedback to make sure it doesn't break anything it would be great!
I tested it under glazewm win11 and everything was fine
here is the version of AltSnap with the above fix. for those that cannot build from the source.
Hopefully I will release 1.64 soon.
See Issue https://github.com/LGUG2Z/komorebi/issues/362
Referenced here in order not forget too quickly. Also I am sure changes should be made on my size.