honour window position exactly

Description

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.

Platform specific:

on win32 we can use the get_window_frame_sizes gui API to undo the offset

on OSX, no idea

on X11: we are supposed to use the ​_NET_REQUEST_FRAME_EXTENTS request, the problem here is that we don't want to wait for the response (that may never come..) when we create a window..

expose the frame geometry to the server so it can respond to the same ​_NET_REQUEST_FRAME_EXTENTS query

the code is racy: if we connect to the xpra server faster than the window manager responds to our query, we won't have the values available when the first window is created. Very very unlikely even with a local connection, but still theoretically possible... especially if the X11 server is remote (higher latency than the xpra server). Maybe we should cache the value on disk? (per desktop environment) - meh

fix GTK3 support (Gtk.WindowType.POPUP, etc..)

maybe this data should be per monitor (need to create on window per monitor..)

verify that toggling window decorations on and off works, this may need the same workaround we have used on win32 (moving the window to ensure its contents stay in the same place)

We now expose the frame extents (r9605, r9606 only for servers that expose the capability).

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.

ideally, we should update the server default frame extents value if we find that the property is changed on our hidden window (and request a new value whenever anything significant is changed: resolution, etc)

we should probably not send the "frame" value for each window when we are actually using the default value: saving unnecessary traffic and allowing us to update all the windows in one swoop by setting the new global default value

GTK3 is going to require some work (some preparatory work in r9614): the HAS_X11_BINDINGS is too coarse and relies on some gtk2 classes

OSX seems to be working as of r9616, we should add a platform function to get the window frame directly (since we can do that on OSX: we can just copy the window position and dimensions rather than try to figure out how to access the underlying NSWindow for our gdk.Window)

easiest thing to check: connecting and re-connecting should place the window in exactly the same place every time - not even 1 pixel off, on all platforms - except with window managers that decide not to honour what we request... and they do exist!

the window frame size value used will be shown with:

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

Disconnecting and reconnecting from a Fedora 20 client (same branch and revision) has the windows pop up in the same places.

Disconnecting and reconnecting from Windows 8.1 works.

Disconnecting from Fedora 20 and connecting with Win8.1 works...sort of. It won't put Firefox below the task bar, instead it just moves it up a couple pixels so the bottom of the window rests against the task bar.

Will test OSX when I get an OSX machine with a screen big enough to match my other machines..

Will test DPI changes later on as I don't want to mess with those settings with my setup. Maybe I'll mess with Testbench when the interns are done...

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 client.windows=True & features.client_window_properties=True.

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.