_NET_WM_MOVERESIZE for win32 and osx

[totaam]

Issue migrated from trac ticket # 772

component: client | priority: minor | resolution: fixed | keywords: win32 osx window resize

2015-01-02 10:42:55: totaam created the issue

---

Split from #765.

Chrome now runs borderless, but it expects the desktop environment to handle its "initiate move or resize" requests... Which we do on X11 by just forwarding the original _NET_WM_MOVERESIZE X11 message.

On MS Windows, looks like we will need SetCapture and the WM_CAPTURECHANGED event. We can then resize our window until the button is released, emulating what the window manager is expected to do for us.

On OSX, no idea.

[totaam]

2015-02-05 07:48:06: totaam changed status from new to assigned

[totaam]

2015-02-05 07:48:06: totaam changed owner from antoine to totaam

[totaam]

2015-02-05 07:48:06: totaam commented

---

#801 closed as duplicate of this bug.

[totaam]

2015-02-06 01:21:32: afarr commented

---

• Note clicking the minimize button in the chrome window itself locks the button on, making the window non-responsive until a right click in the taskbar minimizes/restores the window. Windows client 0.15.0 r8622 against a fedora 20 0.15.0 r8555 server. (Not sure if this should have a ticket of its own, or share real estate with this other chrome specific ticket?)

[totaam]

2015-02-06 03:42:32: totaam commented

---

afarr: the problem you describe is fixed in recent servers. (just verified with a 0.14.20 beta build at both ends, I believe this was in 0.14.19 and maybe even earlier versions too)

[totaam]

2015-05-28 16:58:43: antoine uploaded file emulate-moveresize.patch (13.0 KiB)

most of the code required for emulating _NET_WM_MOVERESIZE

[totaam]

2015-05-28 17:06:49: antoine edited the issue description

[totaam]

2015-05-28 17:06:49: antoine commented

---

Most of the code required should be in the patch above, and can be tested on posix by setting XPRA_EMULATE_MOVERESIZE=1 (which defaults to "1" on platforms without the X11 bindings).

Still TODO:

• probably a good idea to grab the keyboard and cancel if ESC is pressed
• need to capture the mouse motion events even when it is not hovering over the window (I thought that's what the win32api.SetCapture would do..)
• need to keep track of the button state when we start, so we can cancel when it changes
• need to catch focus-out events and cancel the moveresize state
• need to catch window state changes and cancel (ie: maximize, minimize, etc)
• our resize code triggers new motion events, which makes it go into a loop
• honour width_inc, base_width, etc..

[totaam]

2015-06-07 13:16:11: antoine uploaded file emulate-moveresize-v2.patch (14.2 KiB)

updated patch for trunk

[totaam]

2015-11-20 06:17:04: antoine changed status from assigned to new

[totaam]

2015-11-20 06:17:04: antoine changed owner from totaam to antoine

[totaam]

2015-11-20 06:17:04: antoine commented

---

re-scheduling

[totaam]

2016-03-16 06:15:26: antoine changed status from new to assigned

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2016-09-14 17:23:34: antoine changed status from assigned to new

[totaam]

2016-09-14 17:23:34: antoine changed owner from antoine to afarr

[totaam]

2016-09-14 17:23:34: antoine commented

---

Done in r13720 + r13721 + r13722 + r13723 (chrome compat).

This can be tested with:

• [/browser/xpra/trunk/src/tests/xpra/test_apps/test_window_initiatemoveresize.py]
• applications with client side decorations like chromium (previously unmovable on win32 and osx)

The exact same emulation code can be used on posix platforms using the env var XPRA_MOVERESIZE_X11=0.
The move-resize can be stopped by pressing the break key, which can be configured with the env var XPRA_BREAK_MOVERESIZE (it defaults to "Escape").

@afarr: mostly a FYI since your application uses regular window decorations, but the ability to run google-chrome could come in handy.

[totaam]

2016-09-30 02:47:47: afarr commented

---

Testing with 1.0 r13888 win32 client against 1.0 r13912 fedora 23 server...

The test application resizes as expected.

Google-chrome also moves/re-sizes as hoped (though there are sometimes scrolling issues, but that's an issue for somewhere else).

All that said, I think this is ready to be closed. So, I'll do so.

[totaam]

2016-09-30 02:47:54: afarr changed status from new to closed

[totaam]

2016-09-30 02:47:54: afarr set resolution to fixed