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