Hello, Theoretically yes it could work, but nothing was made to make it easy so far. At-spi listens on a dbus bus which is on an abstract unix socket, and ssh can not forward a unix socket that lives in the abstract space. Using socat can work to serve as a bridge, e.g. when we have this:
$ xprop -root | grep AT_SPI AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-Q2svnMqMbO,guid=d35a9f6b8e4cb757b71746025e8e4965" one can create a socket in the non-abstract space with $ socat ABSTRACT-CONNECT:'/tmp/dbus-Q2svnMqMbO' UNIX-LISTEN:/tmp/listen,fork and then run $ ssh myserver -R '/tmp/foobar:/tmp/listen' which exposses the at-spi bus on /tmp/foobar on the server. And then use $ export AT_SPI_BUS_ADDRESS='unix:path=/tmp/foobar' and then try to run applications. But one gets (process:8353): dbind-WARNING **: 21:30:14.860: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (process:8353): dbind-ERROR **: 21:30:14.860: AT-SPI: Couldn't connect to accessibility bus. Is at-spi-bus-launcher running? while it's working when ssh-ing to localhost. Looking in the exchanged data it seems authentication is missing. A cookie-based authentication could be used instead, but that's not implemented in at-spi. Samuel
