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.
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
.
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)
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')}'
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.
This fix was included in the 3.0.3 release. Feel free to re-open if I have missed something.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2311