Comment 33 for bug 328575

> Now, I will argue that the ssh -Y use case is broken, and what we really want
> is something like VNC with client side fusion-type integration. However - we
> can't actively break the legacy behavior here. People expect "ssh -Y myserver
> firefox" to not break.

There are two ways I can think of to keep it from breaking:
* add a dbus transport that tunnels over X protocol
* have ssh and su forward the dbus connection also

Anything else simply will break. Having two sessions connected to the same X server is not tractable for app developers and gnome developers to get right. There's no coherent semantic to it, since supposedly single-instance things become unpredictably multi-instance, and portions of the desktop you want to talk to become impossible to contact.

autolaunch produces undefined, incoherent, undocumentable behavior. Nobody can explain how to write an app or a per-session desktop daemon that works correctly in all cases if dbus-daemons are launched at random.

Failing actually fixing it (using the X tunnel idea or fixing ssh), my preference is not to autolaunch, but to force people to manually set DBUS_SESSION_BUS_ADDRESS _or_ manually launch dbus-daemon; i.e. make people actually figure out what's going on and deal with it. Then they'll at least understand exactly how it breaks. Autolaunch gives this sort of "well, I'll try to automatically work, but won't really, then fail mysteriously" sort of behavior.

There was a time when ssh and su did not magically handle X forwarding either, and people had to manually set up DISPLAY, and we liked it. In the snow, etc.