starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[FEAT]: Compatability With Altsnap #178

New Issue
Closed
opened 2026-01-05 14:48:46 +01:00 by adam · 9 comments
adam commented 2026-01-05 14:48:46 +01:00
Owner
Copy Link

Originally created by @TooSpooky on GitHub (Feb 23, 2023).

Is your feature request related to a problem? Please describe.
Whilst outside of the scope of the project probably, when moving a window using Altsnap the window does not properly function within Komorebi and it floats freely instead of switching places with another window. When moving a window normally it fixes itself.

Describe the solution you'd like
The ability for Altsnap (i.e press alt and drag) to function as a normal drag within Komorebi, no clue if this would be on either Komorebi or Altsnap's end.

Originally created by @TooSpooky on GitHub (Feb 23, 2023). **Is your feature request related to a problem? Please describe.** Whilst outside of the scope of the project probably, when moving a window using Altsnap the window does not properly function within Komorebi and it floats freely instead of switching places with another window. When moving a window normally it fixes itself. **Describe the solution you'd like** The ability for Altsnap (i.e press alt and drag) to function as a normal drag within Komorebi, no clue if this would be on either Komorebi or Altsnap's end.
adam added the enhancement label 2026-01-05 14:48:46 +01:00
adam closed this issue 2026-01-05 14:48:46 +01:00
adam commented 2026-01-05 14:48:46 +01:00
Author
Owner
Copy Link

@RamonUnch commented on GitHub (Mar 10, 2023):

Would not it be enough to call komorebic toggle-float on a ahk script on Alt+Click? like this the window would be go to float mode and when you release Alt+Click the ahk script would would have to call toggle-float again. I am the maintainer of AltSnap.

@RamonUnch commented on GitHub (Mar 10, 2023): Would not it be enough to call `komorebic toggle-float` on a ahk script on Alt+Click? like this the window would be go to float mode and when you release Alt+Click the ahk script would would have to call `toggle-float` again. I am the maintainer of AltSnap.
adam commented 2026-01-05 14:48:46 +01:00
Author
Owner
Copy Link

@TooSpooky commented on GitHub (Mar 10, 2023):

Thanks for the reply, I'll have to see if I can try that out. I'm not all that familiar with AHK or the like so I didn't think of that. You've been super helpful as maintainer of altsnap in the past by the way, I appreciate it.

@TooSpooky commented on GitHub (Mar 10, 2023): Thanks for the reply, I'll have to see if I can try that out. I'm not all that familiar with AHK or the like so I didn't think of that. You've been super helpful as maintainer of altsnap in the past by the way, I appreciate it.
adam commented 2026-01-05 14:48:46 +01:00
Author
Owner
Copy Link

@RamonUnch commented on GitHub (Mar 10, 2023):

I tried very simply this script alongside AltSnap

!LButton::
	if GetKeyState("Alt")
	{
		alt_click_started = 1;
		MsgBox, Alt+Click Started
	}
return

!LButton Up::
	if alt_click_started
	{
		alt_click_started = 0;
		MsgBox, Alt+Click Finished
	}
return

Unfortunately it cannot work because AltSnap has to block the mouse event so AHK cannot get it.
It is possible in theory by modifying AltSnap, however before trying to do this I would like to know if it is worth it.

So the question is: When making a window floating, then moving it to where it belongs, then making it unfloat, is the behavior what would be wanted?

There is another problem and it is that I can toggle float mode with a command but there seems to be no methods to just enable float mode and then disable it, It would be nice if komorebic could handle that (with an additional reference counter) so that if a window is already floating and someone sends komorebic make-float then komorebic unmake-float the window would be still floating at the end. I could probably create a named pipe and communicate more deeply with komorebic but it starts to be quite more complex.

@RamonUnch commented on GitHub (Mar 10, 2023): I tried very simply this script alongside AltSnap ```ahk !LButton:: if GetKeyState("Alt") { alt_click_started = 1; MsgBox, Alt+Click Started } return !LButton Up:: if alt_click_started { alt_click_started = 0; MsgBox, Alt+Click Finished } return ``` Unfortunately it cannot work because AltSnap has to block the mouse event so AHK cannot get it. It is possible in theory by modifying AltSnap, however before trying to do this I would like to know if it is worth it. So the question is: When making a window floating, then moving it to where it belongs, then making it unfloat, is the behavior what would be wanted? There is another problem and it is that I can toggle float mode with a command but there seems to be no methods to just enable float mode and then disable it, It would be nice if komorebic could handle that (with an additional reference counter) so that if a window is already floating and someone sends `komorebic make-float` then `komorebic unmake-float` the window would be still floating at the end. I could probably create a named pipe and communicate more deeply with komorebic but it starts to be quite more complex.
adam commented 2026-01-05 14:48:46 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Mar 10, 2023):

https://github.com/LGUG2Z/komorebi/issues/34 This issue has more details of a prior investigation into something similar. When I have some time this weekend I'll try to play around with AltSnap + komorebi and see what is going on in the interactions underneath the hood.

@LGUG2Z commented on GitHub (Mar 10, 2023): https://github.com/LGUG2Z/komorebi/issues/34 This issue has more details of a prior investigation into something similar. When I have some time this weekend I'll try to play around with AltSnap + komorebi and see what is going on in the interactions underneath the hood.
adam commented 2026-01-05 14:48:47 +01:00
Author
Owner
Copy Link

@TooSpooky commented on GitHub (Mar 10, 2023):

Pretty much so yes, the behavior I’m thinking of would be the same as simply dragging with your mouse in komorebi, I.E. switching the windows position with another. For the added consistency and easy instead of having to use the title bars to drag.

Potentially the ability to take a floating window and alt dragging it over an unfloating window and unfloating the floating window into that position would also he nice with a modifier, but I’m unsure if that’s too much added complexity.

Thanks for both your interests into the issue! I’m very unfamiliar with this sort of work so apologies I cannot assist much.

@TooSpooky commented on GitHub (Mar 10, 2023): Pretty much so yes, the behavior I’m thinking of would be the same as simply dragging with your mouse in komorebi, I.E. switching the windows position with another. For the added consistency and easy instead of having to use the title bars to drag. Potentially the ability to take a floating window and alt dragging it over an unfloating window and unfloating the floating window into that position would also he nice with a modifier, but I’m unsure if that’s too much added complexity. Thanks for both your interests into the issue! I’m very unfamiliar with this sort of work so apologies I cannot assist much.
adam commented 2026-01-05 14:48:47 +01:00
Author
Owner
Copy Link

@donkee commented on GitHub (May 12, 2024):

It's been a while since this issue has been updated, but I just started using both these apps and was wondering if anybody had looked into this more?

@donkee commented on GitHub (May 12, 2024): It's been a while since this issue has been updated, but I just started using both these apps and was wondering if anybody had looked into this more?
adam commented 2026-01-05 14:48:47 +01:00
Author
Owner
Copy Link

@clownroyal420 commented on GitHub (Sep 19, 2024):

@donkee

It's been a while since this issue has been updated, but I just started using both these apps and was wondering if anybody had looked into this more?

It sounds like we might see support in the next release of AltSnap (with possibly either the night release or next major release of Komorebi).

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 what I have inserted into my komorebi.ahk script (and here's a repo with my komorebei.json and komorebi.ahk:

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

}
@clownroyal420 commented on GitHub (Sep 19, 2024): @donkee > It's been a while since this issue has been updated, but I just started using both these apps and was wondering if anybody had looked into this more? It sounds like we might see support in the next release of AltSnap (with possibly either the night release or next major release of Komorebi). 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 what I have inserted into my `komorebi.ahk` script ([and here's a repo with my komorebei.json and komorebi.ahk](https://github.com/clownroyal420/komorebi-configs/tree/main): ``` ; 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}" } } ```
adam commented 2026-01-05 14:48:47 +01:00
Author
Owner
Copy Link

@RamonUnch commented on GitHub (Nov 17, 2024):

Normally with the latest AltSnap 1.64 things should have improved.

@RamonUnch commented on GitHub (Nov 17, 2024): Normally with the latest AltSnap 1.64 things should have improved.
adam commented 2026-01-05 14:48:47 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 17, 2024):

I am using this integration daily now and it's more than stable enough for everyday use - thank you!

@LGUG2Z commented on GitHub (Nov 17, 2024): I am using this integration daily now and it's more than stable enough for everyday use - thank you!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#178
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?