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

Feature request: Add support for Easy Window Drag #28

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

Originally created by @da-rth on GitHub (Sep 14, 2021).

I found this AutoHotKey script which allows you to move and resize windows by holding down the Alt key + dragging the left/right mouse button, similar to that of the window moving/resizing functionality of bspwm.

The script works as expected, but it appears that komorebi does not detect the window resize events that are emitted when resizing windows via Alt+Drag. Would this type of Alt+Drag window moving/resizing functionality be possible with komorebi?

Originally created by @da-rth on GitHub (Sep 14, 2021). I found this [AutoHotKey script](https://www.autohotkey.com/docs/scripts/index.htm#EasyWindowDrag_(KDE)) which allows you to move and resize windows by holding down the Alt key + dragging the left/right mouse button, similar to that of the window moving/resizing functionality of bspwm. The script works as expected, but it appears that komorebi does not detect the window resize events that are emitted when resizing windows via Alt+Drag. Would this type of Alt+Drag window moving/resizing functionality be possible with komorebi?
adam added the enhancement label 2026-01-05 14:47:47 +01:00
adam closed this issue 2026-01-05 14:47:47 +01:00
adam commented 2026-01-05 14:47:47 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 14, 2021):

I've had a look at the script but I'm still not quite able to visualize the behaviour that you have in mind and how it is different to the current current drag-edge-to-resize and move-to-swap functionality that komorebi has:

jw43pCSELI

Can you share a gif of the desired behaviour and one showing what happens instead when the script is run alongside komorebi?

@LGUG2Z commented on GitHub (Sep 14, 2021): I've had a look at the script but I'm still not quite able to visualize the behaviour that you have in mind and how it is different to the current current drag-edge-to-resize and move-to-swap functionality that `komorebi` has: ![jw43pCSELI](https://user-images.githubusercontent.com/13164844/133328606-07b36621-7661-49d8-ad12-bdd47ef3f2d2.gif) Can you share a gif of the desired behaviour and one showing what happens instead when the script is run alongside `komorebi`?
adam commented 2026-01-05 14:47:48 +01:00
Author
Owner
Copy Link

@da-rth commented on GitHub (Sep 15, 2021):

@LGUG2Z I've attached a screenshot to further highlight the type of behaviour I have described above from a laptop I have running SwayWM:

15092021-154750

I currently don't have access to my Windows machine but will upload a recording as soon as I can.

Some differences between the recording you have provided and the one I have posted above are:

  1. In order to move windows around, you are selecting and dragging the window title bar. With the script, you can simply hold Alt+LMB anywhere above a window to move it around.

  2. In order to resize windows, you are going to the edge of a window and selecting/dragging the resize cursor. Whereas, this script allows you to resize the window by simply holding Alt+RMB anywhere above the window and dragging the mouse left, right, up or down to resize the window.

i3, sway, bspwm and several other window managers have this kind of window dragging/resizing functionality, it would be fantastic to have it in komorebi!

@da-rth commented on GitHub (Sep 15, 2021): @LGUG2Z I've attached a screenshot to further highlight the type of behaviour I have described above from a laptop I have running SwayWM: ![15092021-154750](https://user-images.githubusercontent.com/10499053/133456457-7ea2d96f-5218-4fcb-884c-2f5b2ad1b3a1.gif) I currently don't have access to my Windows machine but will upload a recording as soon as I can. Some differences between the recording you have provided and the one I have posted above are: 1. In order to move windows around, you are selecting and dragging the window title bar. With the script, you can simply hold Alt+LMB anywhere above a window to move it around. 2. In order to resize windows, you are going to the edge of a window and selecting/dragging the resize cursor. Whereas, this script allows you to resize the window by simply holding Alt+RMB anywhere above the window and dragging the mouse left, right, up or down to resize the window. i3, sway, bspwm and several other window managers have this kind of window dragging/resizing functionality, it would be fantastic to have it in `komorebi`!
adam commented 2026-01-05 14:47:48 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 17, 2021):

This would be pretty cool to have. This is quite a big feature and I don't think I will have the time to dedicate to it in the coming weeks/months.

The event emitted by the AHK script is this one, which is not currently mapped to a WindowManagerEvent: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/winevent.rs#L125

I tried mapping it to MoveResizeEnd (https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window_manager_event.rs#L113) to get the AHK script working, and while it does, kinda, it forces too many redraws which makes the system crawl to a halt.

This feature would definitely be better built into komorebi than triggered via an AHK script.

For anyone who would like to try working on this, I would suggest something like this as a starting point:

  • A komorebic command each for toggling easy resizing and easy moving mode, which could be bound to key presses up and down, which map to an enum which stores start and end cursor position in the WindowManager state
enum EasyResize {
    Disabled,
    Started(POINT),
    Finished(POINT),
}
  • When toggled off, the diff between the start and end points can be calculated to create a resize offset (or the window to swap with for EasyMove), and then applied to the window before triggering a workspace layout update
@LGUG2Z commented on GitHub (Sep 17, 2021): This would be pretty cool to have. This is quite a big feature and I don't think I will have the time to dedicate to it in the coming weeks/months. The event emitted by the AHK script is this one, which is not currently mapped to a `WindowManagerEvent`: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/winevent.rs#L125 I tried mapping it to `MoveResizeEnd` (https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window_manager_event.rs#L113) to get the AHK script working, and while it does, kinda, it forces too many redraws which makes the system crawl to a halt. This feature would definitely be better built into `komorebi` than triggered via an AHK script. For anyone who would like to try working on this, I would suggest something like this as a starting point: - A `komorebic` command each for toggling easy resizing and easy moving mode, which could be bound to key presses up and down, which map to an enum which stores start and end cursor position in the WindowManager state ```rust enum EasyResize { Disabled, Started(POINT), Finished(POINT), } ``` - When toggled off, the diff between the start and end points can be calculated to create a resize offset (or the window to swap with for EasyMove), and then applied to the window before triggering a workspace layout update
adam commented 2026-01-05 14:47:48 +01:00
Author
Owner
Copy Link

@rottakore commented on GitHub (Oct 29, 2024):

The problem is not in komorebi or any other WM, the problem is in the AHK script you are using which does not send information back to the system when it started/finished moving, also is the same problem with AltDrag and AltSnap.

@rottakore commented on GitHub (Oct 29, 2024): The problem is not in komorebi or any other WM, the problem is in the AHK script you are using which does not send information back to the system when it started/finished moving, also is the same problem with AltDrag and AltSnap.
adam commented 2026-01-05 14:47:48 +01:00
Author
Owner
Copy Link

@Gxnum commented on GitHub (Nov 18, 2024):

The problem is not in komorebi or any other WM, the problem is in the AHK script you are using which does not send information back to the system when it started/finished moving, also is the same problem with AltDrag and AltSnap.

#32 AltSnap is now compatible with Komorebi (haven't tested it myself yet)

@Gxnum commented on GitHub (Nov 18, 2024): > The problem is not in komorebi or any other WM, the problem is in the AHK script you are using which does not send information back to the system when it started/finished moving, also is the same problem with AltDrag and AltSnap. [#32](https://github.com/LGUG2Z/komorebi/issues/362) AltSnap is now compatible with Komorebi (haven't tested it myself yet)
adam commented 2026-01-05 14:47:48 +01:00
Author
Owner
Copy Link

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

Closing as AltSnap has been updated to support komorebi now 🎉

@LGUG2Z commented on GitHub (Nov 18, 2024): Closing as AltSnap has been updated to support komorebi now 🎉
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#28
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?