Window Movement and Resizing

[24unix]

Hi,
I currently use HypeDock for moving and resizing, as when I started using yabai it was not possible to get the same behaviour.

So, when I hold command, the window under the cursor moves, and when I hold control, it resizes.

Is that currently possible? maybe in conjunction with skhd?

The problem is, like Monterey killed TotalSpaces, Ventura killed HyperDock. It crashes roughly every 24 hours. When that happens, I have to open System Setting and go to HyperDock tab. It then detects that it has crashed and restarts.

[koekeishiya]

Uh not really possible without code changes. In the current structure these actions are bound to mouse-buttons: https://github.com/koekeishiya/yabai/blob/master/src/event.c#L965 and https://github.com/koekeishiya/yabai/blob/master/src/event.c#L998

It would be possible to have this code trigger from a modifier press/release action instead of modifier+mouse_button press/release, however it would need the event tap to listen for kCGEventFlagsChanged events and act appropriately.

Ideally the mouse-actions (move/resize) should be made into commands; I wrote something about that here a long time ago.

[koekeishiya]

Out of curiosity, how would you expect a "modifier" only solution to work. Would there be some timer threshold that the modifier would have to be held down before a command is executed, or should it always execute a command when the modifier key is pressed down.

Lets say when cmd is pressed, it runs a yabai -m window --drag move.begin command, which would tell yabai to activate the mouse-move functionaliy on the window that is below the cursor. If this command is executed immediately when cmd is pressed, it would trigger (incorrectly?) in situations where you might want to do cmd + a to perform some other operation.

I imagine it would be press and hold cmd for <activation time> seconds before that command would trigger. That would introduce some kind of latency to how responsive that operation would be to use, but this is probably not purely about responsiveness, but ergonometry / ease of use.

I guess my question boils down to; is a forced activation delay an acceptable solution?

[24unix]

In HyperDock it seems quite immediate, but maybe it is only triggered if the cursor moves?
So, when I'm in this textarea the mouse cursor is like a line, stays so when I hit command (my move modifier), but whenever I actually move it becomes an arrow. I'll try to make a GIF, but don't know if the pointer is recorded.

Edit: So I think, that --drag move.begin should be triggered if the selected modifier is pressen and the mouse moves.

[koekeishiya]

Right, I'm not sure how that would transfer into a general keybinding system. I'll think some more about the problem statement.

The following is just an FYI:
The reason I ask is that I recently got somewhat motivated for programming lately, and am reworking a hotkey system from scratch. In case you are interested in my current thoughts on that: https://github.com/koekeishiya/meraki/blob/master/examples/merakirc

Just some reasoning as to why:
I am not very fond of how the skhd project is designed, written, and generally managed, so I figured I'd do a from scratch rewrite of what (in my opinion) would be a better piece of keybinding software. Now, this is not aiming for feature parity with skhd or anything like that, which is why it is a separate project. Although it somewhat connects to ideas I had when I made this issue waaay back: koekeishiya/skhd#142