Xpra: Ticket #2311: Forwarding custom X properties

I am using xpra to run the GUI version of emacs on a remote machine using SSH. If I run xprop on the local machine and click on the emacs window shown by xpra I get this output:

_NET_WM_USER_TIME(CARDINAL) = 444334063
_NET_WM_ICON_GEOMETRY(CARDINAL) = 3747, 1406, 163, 34
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x640009e
WM_COLORMAP_WINDOWS(WINDOW): window id # 0x64000a2
XID(CARDINAL) = 6291797
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 104857761
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x64000a0
WM_CLIENT_LEADER(WINDOW): window id # 0x6400001
_NET_WM_PID(CARDINAL) = 9524
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "my_local_machine"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 18 by 2
		program specified resize increment: 8 by 15
		program specified base size: 18 by 2
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "emacs", "Emacs"
WM_ICON_NAME(STRING) = "*Warnings* - emacs@my_remote_machine on my_remote_machine"
_NET_WM_ICON_NAME(UTF8_STRING) = "*Warnings* - emacs@my_remote_machine on my_remote_machine"
WM_NAME(STRING) = "*Warnings* - emacs@my_remote_machine on my_remote_machine"
_NET_WM_NAME(UTF8_STRING) = "*Warnings* - emacs@my_remote_machine on my_remote_machine"

But if I run using X forwarding over SSH I see a couple of extra properties, mandimus_server_port and mandimus_server_host:

mandimus_server_port(STRING) = "23233"
mandimus_server_host(STRING) = "my_remote_machine"
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_ICON_GEOMETRY(CARDINAL) = 3747, 1406, 163, 34
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_PID(CARDINAL) = 19534
_NET_WM_ICON_NAME(UTF8_STRING) = "*scratch* - emacs@my_remote_machine"
_NET_WM_NAME(UTF8_STRING) = "*scratch* - emacs@my_remote_machine"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, WM_SAVE_YOURSELF
WM_CLIENT_LEADER(WINDOW): window id # 0x6400155
WM_LOCALE_NAME(STRING) = "C"
WM_CLASS(STRING) = "emacs", "Emacs"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x640015e
		bitmap id # of mask for icon: 0x6400160
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified size: 1270 by 470
		program specified minimum size: 34 by 2
		program specified resize increment: 16 by 32
		program specified base size: 34 by 2
		window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "my_remote_machine"
WM_ICON_NAME(STRING) = "*scratch* - emacs@my_remote_machine"
WM_NAME(STRING) = "*scratch* - emacs@my_remote_machine"

These extra properties are properties that I scripted emacs to set on any window that emacs creates, so they are nonstandard. The reason I do this is a bit convoluted:

All of this works perfectly with X forwarding. The speech recognition program gets the X properties of whichever window currently has focus, and if it sees my two special properties it knows those are the host and port it should connect to in order to send commands to the emacs associated with that window. I am pretty sure it would work transparently with xpra if it preserved to these properties on the client copy of the window.

I can imagine two different ways to accomplish this:

1) Change xpra to blindly always copy all properties -- I am not familiar enough with the inner workings of X to know if there would be undesirable side effects from this, but possibly it would help more applications transparently work remotely the same way they do locally?

2) Provide an option for users to list specific extra properties they would like to have be copied over.



Thu, 30 May 2019 19:45:39 GMT - jgarvin: cc set


Sat, 01 Jun 2019 11:24:20 GMT - Antoine Martin: status, type changed

We can't blindly copy all X11 properties from server to client, this would break in all sorts of unfunny ways. This synchronization is what makes xpra so difficult to implement: for many of the X11 properties, we have copies on both sides and need to keep them in sync.

We could however blacklist the ones that are never meant to be forwarded and handle the rest. Or just whitelist some specific ones. This would only work with X11 clients, win32 and macos don't have window properties - the html5 client could add them but it wouldn't know what to do with them.

We can use the metadata packets for these new properties and the client already exposes the list of metadata attributes it supports as metadata.supported.


Sun, 16 Jun 2019 12:17:48 GMT - Antoine Martin: owner, status changed

r22963 could be extended / improved, but I don't think we should ever try to synchronize X11 window properties both ways: if the client modifies an X11 property then the server won't know about it.. There are probably some property types that we don't handle well.

Tested using xprop on the server:

xprop -f TEST1 8s -set TEST1 hello-world

Then to remove the property:

xprop -remove TEST1

On the client, we can see debug logging with -d metadata and verify that the property is present using xprop.

@jgarvin: please close if this works for you. (the buildbot is spinning some https://xpra.org/beta builds)


Wed, 03 Jul 2019 14:53:05 GMT - Antoine Martin: status changed; resolution set


Thu, 05 Dec 2019 17:56:58 GMT - jgarvin: status changed; resolution deleted

Sorry for the long delay. I got around to installing the latest client, and when I connect to the server I get assertions. Looks like a unicode vs str problem:

----
Traceback (most recent call last):
  File "/home/prophet/opt/lib/python/xpra/client/client_window_base.py", line 201, in update_metadata
    self.set_metadata(metadata)
  File "/home/prophet/opt/lib/python/xpra/client/client_window_base.py", line 403, in set_metadata
    self.set_x11_property(*metadata.listget("x11-property"))
  File "/home/prophet/opt/lib/python/xpra/client/gtk_base/gtk_client_window_base.py", line 940, in set_x11_property
    prop_set(gdk_window, prop_name, dtype, value)
  File "/home/prophet/opt/lib/python/xpra/x11/gtk_x11/prop.py", line 128, in prop_set
    dtype, dformat, data = prop_encode(target, etype, value)
  File "/home/prophet/opt/lib/python/xpra/x11/prop_conv.py", line 295, in prop_encode
    return _prop_encode_scalar(disp, etype, value)
  File "/home/prophet/opt/lib/python/xpra/x11/prop_conv.py", line 299, in _prop_encode_scalar
    assert isinstance(value, pytype), "value for atom %s is not a %s: %s" % (atom, pytype, type(value))
AssertionError: value for atom STRING is not a <type 'unicode'>: <type 'str'>
2019-12-05 11:52:06,305 failed to set window metadata to '{'x11-property': ('mandimus_server_port', 'latin1', 8, '23233')}'

Fri, 06 Dec 2019 10:35:23 GMT - Antoine Martin:

Looks like a unicode vs str problem

You must be using python2. This problem doesn't occur with the python3 builds I had tested with. Fixed in r24604, which you can apply by hand, or wait for the 3.0.3 release.


Thu, 12 Dec 2019 08:09:24 GMT - Antoine Martin: status changed; resolution set

This fix was included in the 3.0.3 release. Feel free to re-open if I have missed something.


Sat, 23 Jan 2021 05:47:55 GMT - migration script:

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