[WIP] macOS: drag OS window by margin

[Luflosi]

Closes #3683.
This is a very rough first draft implementing this feature. I still need to make this not break anything on non-macOS.
The main issue I currently have with my implementation is getting the mouseDown event from the mouseDown handler to the place where I call performWindowDragWithEvent. I currently have a global variable storing the event, which is really ugly and terrible. I see two alternatives. Either I need to create a function that will be called in the mouseDown handler, which will tell it if the event happened inside the margin. Then the handler could call performWindowDragWithEvent directly after calling _glfwInputMouseClick(). The other alternative I can see is to pass the event into _glfwInputMouseClick() and then propagate it into the mouse_event() function, so I can call glfwPerformCocoaWindowDrag from there. I think the second option is the better one.
What do you think, @kovidgoyal?

@rinkjames while the code is really ugly, it should work, so please test if it works like you want it to. You can use make debug && kitty/launcher/kitty --config NONE -o window_margin_width=10 -o window_padding_width=10 to build and run it.

[kovidgoyal]

I'm somewhat confused. Why does this need to macOS specific? Why not use glfwSetWindowPos() to move the OS Window as needed. Also I dont think this should use the margins of individual windows (i.e. window_margin_width). better to just create a new setting os_window_margin_size that will work even when there is a tab bar and multiple windows per tab. Of course doing so means you also need to fill in those margins with blank rectangles while drawing the os window.

[Luflosi]

Why does this need to macOS specific? Why not use glfwSetWindowPos() to move the OS Window as needed.

While this does not need to be macOS specific, it seems very easy to implement on macOS using this function. Also, using glfwSetWindowPos() will not have the same behaviour on macOS. For example when dragging the window to the very top of the screen, it triggers Mission Control, where the window can be dragged to another virtual desktop or real monitor or put into fullscreen or split screen mode. Dragging and holding the window, while pressing ctrl+right arrow will move the window one virtual desktop to the right. Both of these features would probably be hard to emulate when using glfwSetWindowPos().
This is to say that the behaviour can be manually implemented for X11 but we should just use the intended function on macOS.

Also I dont think this should use the margins of individual windows (i.e. window_margin_width). better to just create a new setting os_window_margin_size that will work even when there is a tab bar and multiple windows per tab.

While I can of course add this setting, I don't really see the advantage this would bring. The current window_margin_width setting seems perfectly adequate to me. It works with one kitty window or multiple kitty windows and with or without a tab bar, no? The only purpose the window margin currently has regarding mouse interaction is to select text by dragging outside the window but the padding can serve this same function. Interacting with programs that grab the mouse from outside the window does not currently work properly as the mouse position isn't updated, so removing this ability and replacing it with window dragging would not really hurt anything IMO.
I thought using the margins of the kitty windows was what you meant in #3683 (comment):

I have no objection to implementing dragging from outside margins
(inside margins will probably someday be used to resize windows via
dragging)

[kovidgoyal]

On Fri, Jun 18, 2021 at 07:32:46AM -0700, Luflosi wrote: > Why does this need to macOS specific? Why not use glfwSetWindowPos() to move the OS Window as needed. While this does not need to be macOS specific, it seems very easy to implement on macOS using this function. Also, using `glfwSetWindowPos()` will not have the same behaviour on macOS. For example when dragging the window to the very top of the screen, it triggers Mission Control, where the window can be dragged to another virtual desktop or real monitor or put into fullscreen or split screen mode. Dragging and holding the window, while pressing <kbd>ctrl</kbd>+<kbd>right arrow</kbd> will move the window one virtual desktop to the right. Both of these features would probably be hard to emulate when using `glfwSetWindowPos()`. This is to say that the behaviour can be manually implemented for X11 but we should just use the intended function on macOS.

That's fine if you want macOS special behavior, that's up to you, but I would want this feature to work on all platforms, not just macOS. As for API design, at least for macOS it seems like you simply need to trigger the drag in the mouse down handler not the mouse move handler, then the event can simply be stored globally only while _glfwInputMouseClick() is running. And it can be stored in GLFWContentView or the GLFWWindow object rather than globally.

<br> > Also I dont think this should use the margins of individual windows (i.e. window_margin_width). better to just create a new setting os_window_margin_size that will work even when there is a tab bar and multiple windows per tab. While I can of course add this setting, I don't really see the advantage this would bring. The current `window_margin_width` setting seems perfectly adequate to me. It works with one kitty window or multiple kitty windows and with or without a tab bar, no? The only purpose the window margin currently has regarding mouse interaction is to select text by dragging outside the window but the padding can serve this same function. Interacting with programs that grab the mouse from outside the window does not currently work properly as the mouse position isn't updated, so removing this ability and replacing it with window dragging would not really hurt anything IMO. I thought using the margins of the kitty windows was what you meant in #3683 (comment): > I have no objection to implementing dragging from outside margins (inside margins will probably someday be used to resize windows via dragging)

The problem with using window margins is the window margin is between the tab bar and the kitty window, so there will be no margin at the top of the OS Window, if the tab bar is at the top. Also, see #3685 for some more motivation for this.

[rinkjames]

@rinkjames while the code is really ugly, it should work, so please test if it works like you want it to. You can use make debug && kitty/launcher/kitty --config NONE -o window_margin_width=10 -o window_padding_width=10 to build and run it.

Just posting here briefly to say that I haven't forgotten about this PR and will test soon. Just been really busy with other work stuff lately. Thanks

[Omnikar]

Any update on this?

[BigBrotherJu]

Any update on this?