When we map a window at a specific location, either because the application requested it or because it was mapped at a specific location previously (hard to distinguish at present), we should ensure that the window contents end up exactly at the specified location. At the moment, we ask GTK to place the window frame there and so windows that have a border and title bar end up moved down + right every time they are mapped.
get_window_frame_sizesgui API to undo the offset
Done for win32 in r9595.
Mostly done for X11 in r9601, as in: it will work as expected in most cases.
The big problem with honouring
_NET_REQUEST_FRAME_EXTENTS is that these requests often come in for windows that are realized but not shown yet (ie: that's what our test app does), so that the application can calculate the offsets before showing the window.
But that also means that we don't have a window model for it yet, so we can't receive the message on the window... and for some reason the client message is not being received by the "WM" class either despite it being registered as an event receiver for the root window which is the target of the message.
import Quartz r=Quartz.NSRect() Quartz.NSWindow.pyobjc_classMethods.contentRectForFrameRect_styleMask_(r, 1) <NSRect origin=<NSPoint x=0.0 y=0.0> size=<NSSize width=0.0 height=-22.0>>
HAS_X11_BINDINGSis too coarse and relies on some gtk2 classes
work in progress patch to allow us to access at least some X11 properties with the gi bindings (GTK3)
Still TODO, moved some refactoring issues to ticket:640#comment:29.
New TODO: we should at least investigate #501
Ready for testing. (#501 makes no difference here - just confuses me more)
Things to check:
xpra info | grep -i "client.window.frame-sizes"
It would be interesting to see if this value changes when the DPI changes (esp with OSX and win 8+) - we don't update the defaults which are sent during the initial connection, but the window value should get updated (I hope, assuming the frame size even changes - if not, toggling opengl on and off probably does it as it re-displays the window).
Started a Fedora 21 9689 trunk server:
Testing the OSX 0.15.4 r9951 client against a 0.15.4 r9951 fedora 20 server - the windows do indeed display in the same place when re-connecting. Except - when a window is being displayed on the border between two monitors, upon re-connection the window (firefox, xterm, whatever) will display on whichever display they were "more" displaying on before the disconnection. (Confirmed same behavior with windows 0.15.4 r9951 client against same server session.)
Not sure if this behavior is just the result of the xFakeXinerama handling of multiple displays or not, but I'll attach info files for before disconnect and after reconnect with the osx client.
Testing with the OSX client with adjusting resolutions between connection (osx 10.9 doesn't provide any means that I have discovered to adjust in terms of DPI, but it does give four, and only four, resolution scaling options) ... the first thing I discovered is that
xpra info | grep -i "client.window.frame-sizes" gives no response.
xpra info | grep -i "client.window" only outputs
The client output does give some insight though:
At a resolution (as indicated by system preferences) of 2560 x 1440:
2015-07-16 17:29:47,928 desktop size is 2960x2490 with 1 screen(s): 2015-07-16 17:29:47,929 'schadenfreude.local' (1044x878 mm - DPI: 72x72) 2015-07-16 17:29:47,930 monitor 1 1680x1050 at 1280x1440 (592x370 mm - DPI: 72x72) 2015-07-16 17:29:47,931 monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
At 2048 x 1152
2015-07-16 17:59:36,969 desktop size is 2720x2340 with 1 screen(s): 2015-07-16 17:59:36,969 'schadenfreude.local' (959x825 mm - DPI: 72x72) 2015-07-16 17:59:36,969 monitor 1 1440x900 at 1280x1440 (508x317 mm - DPI: 72x72) 2015-07-16 17:59:36,970 monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
At 1600 x 900
2015-07-16 18:00:49,363 desktop size is 2560x2240 with 1 screen(s): 2015-07-16 18:00:49,364 'schadenfreude.local' (903x790 mm - DPI: 72x72) 2015-07-16 18:00:49,364 monitor 1 1280x800 at 1280x1440 (451x282 mm - DPI: 72x72) 2015-07-16 18:00:49,364 monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
At 1280 x 720
2015-07-16 17:32:32,382 desktop size is 2560x2080 with 1 screen(s): 2015-07-16 17:32:32,382 'schadenfreude.local' (903x733 mm - DPI: 72x72) 2015-07-16 17:32:32,382 monitor 1 1024x640 at 1280x1440 (361x225 mm - DPI: 72x72) 2015-07-16 17:32:32,383 monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
With a windows 8.1 client (resolutions picked at near random... values plucked from server side output, matching client side details)
At 3840 x 2160
2015-07-16 18:14:58,074 client root window size is 5120x2160 with 1 displays: 2015-07-16 18:14:58,074 '1\WinSta-Default' (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-07-16 18:14:58,075 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-07-16 18:14:58,075 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-07-16 18:14:58,109 server virtual display now set to 5120x2560 (best match for 5120x2160)
At 2048 x 1152
2015-07-16 18:19:46,015 client root window size is 3328x1152 with 1 displays: 2015-07-16 18:19:46,016 '1\WinSta-Default' (880x304 mm - DPI: 96x96) workarea: 3328x1112 2015-07-16 18:19:46,016 DISPLAY1 2048x1152 at 1280x0 (621x341 mm - DPI: 83x85) workarea: 2048x1112 2015-07-16 18:19:46,016 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-07-16 18:19:46,071 server virtual display now set to 3520x1196 (best match for 3328x1152)
At 1600 x 900
2015-07-16 18:21:52,538 client root window size is 2880x900 with 1 displays: 2015-07-16 18:21:52,538 '1\WinSta-Default' (762x238 mm - DPI: 96x96) workarea: 2880x860 2015-07-16 18:21:52,540 DISPLAY1 1600x900 at 1280x0 (621x341 mm - DPI: 65x67) workarea: 1600x860 2015-07-16 18:21:52,540 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-07-16 18:21:52,551 DPI set to 96 x 96 2015-07-16 18:21:52,571 sent updated screen size to 1 clients: 3120x1050 (max 8192x4096)
This last entry, however, resulted from my changing the resolution while still connected.
The plus is that the client and server both outputted updated values, and the display adjusted as expected.
The down-side is that a control-C seems to fail to disconnect the client... the server acknowledges the CTRL_C and disconnects, but the client is hung/
Not Responding. I'll file another ticket for that.
Let me know if you need any other info regarding the window frame-sizes as resolutions change, or any more than the info for the multi-display window placement on re-connect.
multi-display info with window split between two displays before disconnection
multi-display info with window split between two displays after reconnection
the windows do indeed display in the same place when re-connecting. Except - when a window is being displayed on the border between two monitors..
That's fine, the window manager decides that it isn't a good location and overrides us.
xpra info | grep -i "client.window.frame-sizes"gives no response....
Ah, this part is in trunk only...
I think we can close this ticket and follow up in #919
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/885