Xpra: Ticket #772: _NET_WM_MOVERESIZE for win32 and osx

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 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.

Thu, 05 Feb 2015 07:48:06 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to Antoine Martin
status changed from new to assigned

#801 closed as duplicate of this bug.

Thu, 05 Feb 2015 07:51:07 GMT - John1221: cc set

cc johnss1221@… added

Fri, 06 Feb 2015 01:21:31 GMT - alas:

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?)

Fri, 06 Feb 2015 03:42:32 GMT - Antoine Martin:

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)

Thu, 28 May 2015 15:58:43 GMT - Antoine Martin: attachment set

attachment set to emulate-moveresize.patch

most of the code required for emulating _NET_WM_MOVERESIZE

Thu, 28 May 2015 16:06:49 GMT - Antoine Martin: description changed

description modified (diff)

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..

Sun, 07 Jun 2015 12:16:10 GMT - Antoine Martin: attachment set

attachment set to emulate-moveresize-v2.patch

updated patch for trunk

Fri, 20 Nov 2015 06:17:03 GMT - Antoine Martin: owner, status, milestone changed

owner changed from Antoine Martin to Antoine Martin
status changed from assigned to new
milestone changed from 0.16 to 0.17

re-scheduling

Wed, 16 Mar 2016 06:15:26 GMT - Antoine Martin: status, milestone changed

status changed from new to assigned
milestone changed from 0.17 to 0.18

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

milestone changed from 0.18 to 1.0

Milestone renamed

Wed, 14 Sep 2016 16:23:34 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to alas
status changed from assigned to new

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.

Fri, 30 Sep 2016 01:47:46 GMT - alas:

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.

Fri, 30 Sep 2016 01:47:53 GMT - alas: status changed; resolution set

status changed from new to closed
resolution set to fixed

Sat, 23 Jan 2021 05:05:30 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/772