Compatibility with Komorebi

[RamonUnch]

See Issue LGUG2Z/komorebi#362

Referenced here in order not forget too quickly. Also I am sure changes should be made on my size.

[LGUG2Z]

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 🤔

[RamonUnch]

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.

[LGUG2Z]

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.

[RamonUnch]

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.

[aspauldingcode]

Status still open? Working/not yet?

[clownroyal420]

@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.

2024-09-19.19-07-52.mp4

#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}"
    }

}

[aspauldingcode]

here's a video demonstration followed by what I have inserted into my komorebi.ahk script

Dang that's actually really close. Nice script!

[catvox]

It is so cool!! I have disabled my altsnap!

[alex-ds13]

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?

[alex-ds13]

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!

[Andrew6rant]

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)

[aspauldingcode]

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!!