Oof. Yeah, the handling of SSH usernames is a bit messed up. The SSH
username has traditionally been treated as a meta-parameter of sorts.
It is taken from the Via parameter if it is specified in that parameter
(or its GUI equivalent in the "TurboVNC Viewer Options" dialog), or it
is taken from the Server parameter if it is specified in that parameter
(or its GUI equivalent in the "New TurboVNC Connection" dialog), or it
defaults to the local username if it is unspecified. The SSH username
meta-parameter is stored in a string inside the Params instance, and the
string is set when the Via or Server parameter is set or when the "SSH
user" field is set and "OK" is clicked in the Options dialog. In prior
versions of TurboVNC, this had the following ramifications, which were
arguably confusing:
- If "Use VNC server as gateway" was checked in the Options dialog, the
"SSH user" field was ignored if the SSH username was specified in the
Server parameter (and/or the "VNC server" field in the Connection dialog.)
- The value of the "SSH user" field was not saved and restored between
invocations of the Options dialog unless the gateway host was also
specified. This is because, if the gateway host is unspecified, the SSH
username becomes associated with the Server parameter, and the Server
parameter is ephemeral (i.e. it has no default value and is not saved
and restored, although it can be specified in a .turbovnc file or
default.turbovnc.)
IMHO, this behavior is broken, because it violates the implicit contract
whereby everything in the Options dialog is saved (and will be restored
not only on the next invocation of the dialog but also on the next
invocation of the TurboVNC Viewer) when "OK" is clicked. The
introduction of per-host options in TurboVNC 3.1 further broke the
already broken behavior. It isn't clear in which cases resetting other
parameters with Options dialog equivalents (Via in particular) should
also reset the SSH username, and apparently the SSH username is being
reset in some cases in which it shouldn't be.
The only clean solution I can think of is to stop treating the SSH
username as a meta-parameter and leave it attached to the parameter in
which it is specified (Via or Server.) That would have the following
ramifications:
- When using the Tunnel parameter (or checking "Use VNC server as
gateway"), the SSH username would need to be specified in the Server
parameter or the "VNC server" field. The text in the Connection dialog
and the documentation of the Server parameter would be modified to
clearly indicate this.
- The Options dialog would have a single "Gateway" field that acts just
like the "VNC server" field in the Connection dialog, i.e. the SSH
username would be specified by prefixing user@ to the hostname.
Checking "Use VNC server as gateway" would disable that field. New text
in the Options dialog would direct users as to the correct usage of the
"Gateway" field.
That would be a slight feature regression against 3.0.x, but again, the
behavior of 3.0.x and prior was somewhat confusing.
The proposal above would fix both of the issues you report.
The feature you request would be dead simple to implement, just a
one-line modification that makes the LocalUsernameLC parameter affect
the SSH username as well as the User parameter.
DRC