_NET_WM_MOVERESIZE for win32 and osx

[Antoine Martin]

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.

[Antoine Martin]

#801 closed as duplicate of this bug.

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

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

[Antoine Martin]

most of the code required for emulating _NET_WM_MOVERESIZE

[Antoine Martin]

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

[Antoine Martin]

updated patch for trunk

[Antoine Martin]

re-scheduling

[Antoine Martin]

Milestone renamed

[Antoine Martin]

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.

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

[migration script]

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