Xpra: Ticket #212: honour window movements
since r1089 we honour client triggered window resizes (see #107), we should probably also honour client window movements.
Unfortunately this is more tricky... see #158
- avoid loops, the client will send a configure event when the window is moved... which can trigger another move, etc..
- as per #170: there are small offsets to do with window borders - this needs sorting out too
- too many places where the same information is kept, making it difficult to synchronize everything - maybe more of it should be derived/calculated rather than stored?
Tue, 13 Nov 2012 09:25:00 GMT - Antoine Martin: attachment set
set to honour-window-move.patch
if we find that the client window has moved, move our corral window and pass it on to the client
Tue, 13 Nov 2012 09:27:16 GMT - Antoine Martin: status, description changed
changed from new to accepted
Tue, 13 Nov 2012 09:28:37 GMT - Antoine Martin: attachment set
set to honour-window-movep2.patch
missing bits from the first patch
Fri, 16 Nov 2012 20:29:52 GMT - daemonpnz: cc set
Wed, 20 Mar 2013 14:50:24 GMT - Antoine Martin: milestone changed
changed from 0.9 to future
re-scheduling for a later version
Thu, 17 Oct 2013 11:35:26 GMT - Antoine Martin: milestone changed
changed from future to 0.12
0.12 should deal with focus/move issues
Sun, 16 Mar 2014 11:51:39 GMT - Antoine Martin: status changed
changed from accepted to new
Many changes in this area because of #532, and window moves now done in r5811.
Please check on a variety of platforms using the test applications:
Especially with tricksy setups like multi-monitor: when the windows are on the secondary one (to make sure the coordinates used for the calculations are absolute and not relative to whatever screen you are on)
And maybe also check for regressions in fullscreen/maximize/etc (just in case):
Sun, 16 Mar 2014 11:51:49 GMT - Antoine Martin: owner changed
changed from Antoine Martin to alas
Wed, 19 Mar 2014 01:03:22 GMT - alas:
- test_window_move - on osx this seems to work as expected, but on windows the
move me button doesn't move the window - though if moved manually, the location is output in the xterm from which the process is spawned.
- test_window_resize - seems to work as expected, osx and windows (though the
fast resize is not really very fast at all on osx).
- test_window_mapresize - on both osx and windows it seems to work as expected, but after ~ 8 seconds the window closes (whether any resizing has been done or not) ... coordinates do not seem to be relative to the screen, but rather relative to the total display size.
- test_window_maximize - this seems to work as expected, on a single window osx or multi-window windows set up, though the
unmaximize me button doesn't work, which is easily worked around by using the unmaximize button supplied by the OS.
Wed, 19 Mar 2014 06:16:26 GMT - Antoine Martin:
- move: I am unable to reproduce the problem on win32, what revision are you testing with? can you post the client and server log with "
-d window" (include only the relevant section)
fast_resize may well behave differently on different platforms, depending on how quickly they respond to our request to resize the window (more slowly on OSX it seems). As long as things end up looking OK, we're good.
- mapresize: it was meant to close after 10 seconds, I've changed it in r5851
- maximize: that's a bug: #537
Thu, 20 Mar 2014 21:30:12 GMT - alas:
I think the version was the issue with the
test_window_move - I was using r5444.
Testing again with r5828 the
move me button causes the window to "hop" as expected.
This looks like it should all be good. (I assume you no longer need the client and server logs?)
Fri, 21 Mar 2014 00:37:53 GMT - Antoine Martin: status changed; resolution set
changed from new to closed
set to fixed
Sat, 23 Jan 2021 04:48:34 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/212