Xpra: Ticket #170: preserve workspace mapping

It would be nice if we could preserve the workspace that windows are shown on when we disconnect, so that when we re-connect they re-appear at the same coordinates (we're not far off at the moment) and on the same workspace.

This should be do-able by keeping the value of _NET_CURRENT_DESKTOP for the window shown on the client. Which means having the ability to store properties on the server. This value would not actually be used by the xpra server, just kept for the client.

Or more simply, by using gtk's get_number()



Sun, 05 Aug 2012 14:15:18 GMT - Antoine Martin: status, description changed


Tue, 28 Aug 2012 16:25:43 GMT - Antoine Martin: attachment set

this patch preserves workspace, and potentially other properties that clients can set


Tue, 28 Aug 2012 16:29:13 GMT - Antoine Martin:

The patch above works, but now that we have multi-client support (see #41), how is this meant to work?

Options:

???

Comments welcome.


Wed, 29 Aug 2012 14:27:33 GMT - Antoine Martin:

workspace mapping is preserved as of r1429. Notes about this code:


Still TODO:


Thu, 30 Aug 2012 10:30:00 GMT - Antoine Martin: status changed; resolution set

There is still a few pixels difference between where we want the window to show up and where it actually shows up.. I think that's because of window decorations and such, not going to bother with it for now.


Thu, 30 Aug 2012 14:21:14 GMT - Norman Rasmussen:

Replying to antoine:

The patch above works, but now that we have multi-client support (see #41), how is this meant to work?

even without multi-client support, how do we handle disconnecting and reconnecting from a different client?

Replying to antoine:

/var/lib/dbus/machine-id will change when the client is rebooted, this seems sub-optimal. What about using /etc/hostname (which returns fqdn is present) or gethostid(3) (which seems to return primary ip address)


Thu, 30 Aug 2012 15:19:01 GMT - Antoine Martin:

If you are re-connecting from a different client, then the workspace (and any other "client properties" against a window) won't be preserved. This is by design. (although this can be changed, I didn't think it would make sense)

AFAIK, the machine-id files are not re-generated after installation:

The /etc/machine-id file contains the unique machine id of the local system that is set during installation.

Thu, 30 Aug 2012 15:21:12 GMT - Norman Rasmussen:

debian & ubuntu doesn't seem to have /etc/machine-id. not a biggie.


Tue, 04 Sep 2012 17:35:55 GMT - Antoine Martin:

On debian & ubuntu, the dbus machine-id will be used, this is also meant to be unique (not re-generated).

I've just found out that a number of window managers (or in some cases, versions of the same WM, and probably also different configurations of the same WM..) do not use workspaces but viewports.. And although we can get some sort of information on where the window is (by looking up _NET_DESKTOP_VIEWPORT on the root window), there is *nothing* we can do to request which viewport the window will be shown on when we create it! (according to the spec, we can switch to that viewport, but not request it for a window...)


Tue, 11 Sep 2012 09:31:11 GMT - Antoine Martin:

Also, this was causing all sorts of bugs, so I've disabled it for now.


Mon, 12 Nov 2012 11:00:35 GMT - Antoine Martin: attachment set

much safer and simpler code - which works ok so far


Mon, 12 Nov 2012 11:31:44 GMT - Antoine Martin:

done in r2106 - now works reliably, without any side effects - only a slight flicker as the window is first shown on the current desktop before being moved to the correct one... I have tried sending the message when the window is realized and not yet mapped, but that does not work :(

Note: it would be nice if we could restore it exactly where it was, but we don't do that yet as we do not take into account the window manager's borders... so the window moves down and to the right a little bit each time.


Sat, 23 Jan 2021 04:47:26 GMT - migration script:

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