Define behavior around zwgc and remote X11 sessions

[jdreed]

A desire has been expressed to change how zwgc behaves for remote logins. Specifically, there is a debate about whether or not it is desirable for zwgc to run when connecting to a Debathena machine with SSH and X11 forwarding. Some people expect this behavior and either like it or configure it to their needs, others find it intrusive and wish to disable it.

For the history surrounding this, see #137

[jdreed]

I propose the following solution, which keeps the default Athena behavior but provides customizability.

The system dotfiles check for the presence of a zephyr variable (tentatively named "remotex11"). If zctl show remotex11 | awk '{print $2}' returns 'false' and $DISPLAY is set, then don't run zwgc. Otherwise, do.

Users who find zwgc intrusive can run a one-time command of "zctl set remotex11 false". Since we also check for $DISPLAY being set, users who have remotex11=false and fallback=true will get a ttymode zwgc in regular ssh sessions, as they would expect.

[xavid]

I feel like we should make some effort to make the default behavior less confusing. The most common case for most users where you would SSH with X forwarding is from a cluster machine. In this case, you get two copies of each window gram, and the normal methods of turning off windowgrams don't effect the remote set. The fact that it's totally nonobvious that some of your windowgrams are coming from the remote server, especially if you're not actually taking advantage of X forwarding. While some people are used to the current behavior, it is not very intuitive and it seems to me that most new Athena users would not want the current behavior.

I would propose that we have as default behavior not running zwgc for SSH sessions of any type, but document this as a change in Debathena and provide a simple way using zephyr variables to enable the old behavior.

(FWIW, up until the point where I disabled zwgc all together, I was surprised every single time this happened when I was on a cluster machine. Interpret this as you will.)

[jdreed]

Replying to xavid:

The fact that it's totally nonobvious that some of your windowgrams are coming from the remote server, especially if you're not actually taking advantage of X forwarding.

I'm not sure what you mean by "not taking advantage of X forwarding". We don't enable X11 forwarding by default right? Users should still have to type ssh -X (or -Y) if they want X forwarding, so I'm not sure when a user would be connecting with X forwarding without knowing it.

I would propose that we have as default behavior not running zwgc for SSH sessions of any type, but document this as a change in Debathena and provide a simple way using zephyr variables to enable the old behavior.

Fair enough, we can simply invert the description above and only run zwgc in .login/.bash_login if $DISPLAY is set and the zephyr variable "remotex11" is true. I think if $DISPLAY is not set (ie: a tty ssh session), we should run zwgc regardless, because it won't have any effect anyway unless the user has set fallback=true.

[xavid]

Replying to jdreed:

I'm not sure what you mean by "not taking advantage of X forwarding". We don't enable X11 forwarding by default right? Users should still have to type ssh -X (or -Y) if they want X forwarding, so I'm not sure when a user would be connecting with X forwarding without knowing it.

It's always been my experience on Athena 9 that I get X forwarding even when I don't explicitly request it. Maybe this is a change from Athena 9 to Athena 10, or maybe I messed up my dotfiles Freshman year (though I've seen other people get X forwarding without expecting it in clusters, and I don't see any obvious configuration of this in my dotfiles...)

Fair enough, we can simply invert the description above and only run zwgc in .login/.bash_login if $DISPLAY is set and the zephyr variable "remotex11" is true. I think if $DISPLAY is not set (ie: a tty ssh session), we should run zwgc regardless, because it won't have any effect anyway unless the user has set fallback=true.

Sounds good to me. (Aside from implementation details, this is not running zwgc by default in either case.)