xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 4 months ago

#2311 closed enhancement (worksforme)

Forwarding custom X properties

Reported by: jgarvin Owned by: jgarvin
Priority: major Milestone: 3.0
Component: core Version: 2.5.x
Keywords: Cc: joseph.h.garvin@…

Description

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:

  • I locally run a speech recognition program
  • I have written an extension for emacs that causes emacs to listen on a socket for instructions from my speech recognition program.
  • I tend to run both local and remote instances of emacs, and I want my speech recognition program to seamlessly drive one or the other depending on which window has focus.

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.

Change History (4)

comment:1 Changed 5 months ago by jgarvin

Cc: joseph.h.garvin@… added

comment:2 Changed 5 months ago by Antoine Martin

Status: newassigned
Type: defectenhancement

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.

comment:3 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to jgarvin
Status: assignednew

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

comment:4 Changed 4 months ago by Antoine Martin

Resolution: worksforme
Status: newclosed
Note: See TracTickets for help on using tickets.