the control file of the package should indicate it provides vnc-viewer so it can be used with
update-alternatives.

Hi Alan,
Providing the virtual package name vnc-viewer isn't enough to make it
manageable via alternatives. We also need to call udpate-alternatives in
the postinst. So these are the open issues:

* there's no virtual package name vnc-viewer in
  /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
  We should get this added.

* Since update-alternatives assumes command line compatibility: I can't
  seem to find a list of options that has been agreed upon that all VNC
  viewers providing "vnc-viewer" must support

* Once this is resolved we can easily add a "Provides: vnc-viewer" and
  handle the alternatives.

Anybody wants to pick this up?
 -- Guido

Hi,

Guido Günther wrote:
[...]

Before that, what is the use case?  I.e., what would a script or
user-run command look like that invokes a vnc-viewer without caring
which vnc-viewer that is (as many programs open a text editor today)?

I suppose this would allow QEMU (with its current upstream default
settings) to launch a vnc viewer instead of just saying

	VNC server running on `127.0.0.1:5900'

on stdout.  It might run

	vnc-viewer localhost

Due to bug#645464, I don't know what a command that specifies the port
would look like.

Is there non-distro-specific common practice we can try to follow
here?  Maybe something in the libvirt world?  (Sorry, I'm out of
touch.)

Although all I have to contribute is questions at the moment, because
of the qemu usecase this sounds interesting.

Just using vnc-viewer instead of having to remember that it's called
tight-vnc, gvncviewer or similar sound reasonable to me in case you
just want a basic remote display.


Nothing that I know of.

Indeed it would be nice to make virsh directly launch a vnc-viewer
(which would be doable once we have this bug fixed).
Cheers,
 -- Guido

Guido Günther wrote:

I guess display == port - 5900.

Right, it seems virt-manager uses python-gtk-vnc directly.

One way is to imitate the history of the EDITOR variable and "editor"
command.

 1. Hardcode gvncviewer.
 2. Some users might want something different and introduce a patch
    to respect a VNCVIEWER envvar that gives them a choice.
 3. Some people building from source might want a different default
    VNCVIEWER, so they can introduce a patch to make it configurable
    at compile time.
 4. Distro integrators notice there is no one right answer for the
    compile-time setting and use update-alternatives to abstract it
    away.
 5. xdg-utils gains an xdg-vncviewer command to handle running
    ${VNCVIEWER-vnc-viewer}, making the application-specific logic
    from steps (2) and (3) obsolete.

So there is no need to wait. :)

More seriously, gvncviewer, directvnc, vncviewer from TightVNC,
and vncviewer from RealVNC all seem to support the <host>[:<display>]
syntax.  I guess that is the common interface.

Some also support <host>::<port>.

gtkvncviewer does not accept a server name on the command line.