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!