On Thu, Oct 20, 2011 at 07:58, Keith Lofstrom <[email protected]> wrote:
> I will look at vnc some more, but as I understand it, vnc copies
> desktops, not the single window outputs of single applications
> ("clients" in X parlance). I specifically do NOT want to share
> whole desktops.
vnc does start its OWN x server. on that server, you can choose to
run no window manager and only one client that takes up the entire
desktop (and the server can run at any geometry, being virtual...say,
exactly the size of one perfectly sized xterm, or just 100x100 pixels
if you wanted to cram it onto a tablet in the corner), and then when
someone else connects to it, all they see is an xterm, and even if
they manage to close the xterm, they can't do anything else to the
remote session--there's no clicking on the root window to bring up a
context menu, because a window manager, not X win itself, provides
that.
i guess one thing that might bug you is that you can't have two
cursors at the same time. i'd argue that you actually don't want
that--does your app actually know what to do when two people try to
focus different modal dialog boxes or form fields simultaneously? i
know my web browser will just move focus to whichever form field was
clicked last, and then both people are typing into the same field
without intending to. the way vnc handles it is to allow either
person to move *the* cursor. you can certainly play cursor tug of war
and type alternating characters from alternating displays if you want
to, tho.
so it sounds to me like you can do what you want, and without much
fiddling (the default vnc session is 'twm', but you set what clients
are run at startup via the file .vnc/xstartup, so you just replace all
that with "/path/to/xterm -your-options", run vncserver, and you are
done making your example work.)
> I'll provide an example. Using the special duplication process,
> (which I still need a name for!) I bring up an xterm on the desktop
> of display/machine A, and that same xterm (via some magic) appears
> on the otherwise completely independent display/machine B connected
> over the internet.
there are two ways to go about this with vnc, both of which are not 0
configuration (require running at least one command). but even in
your proposed setup of a multi-display-aware app, someone has to grant
someone else permission to connect to their x server, so i don't think
this is an additional hurdle, merely the same hurdle you'd already be
jumping over at least once per login.
in my proposed setup, machine B has to run "vncviewer A:1"; A's
"desktop" (which in this case consists entirely of the xterm) doesn't
just appear on B.
the other option is that at least one of the vnc variants actually
reaches out and connects to a remote client (which would of course
need to be savvy enough to have granted you connection authority via
xauth, which is way harder that running the vncviewer command imho
(the arguments never change to vncviewer; they almost certainly will
via xauth).
it appears that ultravnc server might be one that connects outbound to
a remote "client" (aka user) for you. i've never used that
functionality, so you get to investigate it yourself.
vnc handles all authentication itself (in the 'vncviewer A:1 scenario
above), meaning you set a password for the connection which the user
at B will need to know. it can in fact be an empty password, at least
with tightvnc.
> With my focus over that xterm on machine A,
> mouse movements and keyboard movements are fed to the xterm client
> (which could be running on machine C, BTW). The user on machine
> B sees an identical xterm window on their own entirely different
> desktop, and can also feed mouse and keyboard information to it
> when that xterm is in focus. Otherwise, the desktop of A is invisible
> to B, and of B invisible to A. There can be entirely different
> applications running, screen sizes, hardware, etc.
all of that holds with vnc (either person can drive the
cursor/keyboard, and the other person sees it scooting around; since
vncserver is itself a CLIENT to the actual :0 desktop, there is no :0
leakage to or from B, whose vncviewer is also a client to *its* :0),
including that the xterm client could be running on C like this:
on A: <give C permission via xauth or xhost (shudder) to display
clients on its :1 $DISPLAY>
on C:
export DISPLAY=A:1
xterm
you can of course run whatever app or combination or apps you want on
A's vnc (:1) desktop, including firefox or openoffice or the gimp
(note, the gimp is really hard to use without a window manager!).
heck, you can run many apps, again even without a window manager
(-geometry is your friend) and give the person access to all of them.
or you can just use a WM and get virtual desktops inside that virtual
desktop to allow better multi-window handling/display--it just depends
on how much you trust the remote client.
speaking of trust, vnc offers a read-only mode in case you really
don't trust the client. they just get to be voyeurs, not
participants. doesn't sound like you need it, but you haven't
actually told us what you're doing with this so i am offering extra
options.
> I suppose "Double" could be a fake desktop with no physical
> hardware attached, which in turn is accessed by two instances
> of vnc running on machine/displays A and B. Perhaps the fake
> desktop could be on a real video card with no display attached.
> But that multiplies the watts and the computation involved.
>
> Is it clearer what I want?
i think i got it from the start, though you didn't seem to get that
the solution i offered might work for you.
and while what i am describing is not the exact *implementation* you
seem to be hung up on having (an application or maybe X11 library that
is multi-connect aware, if i am reading you correctly), i maintain
that it is a valid, non-kludgey, functional equivalent. it's actually
supra-functional, since you can use it on ANY app that already works
under x with minimal fuss. oh, and it's cross-platform, in case you
were ever at the library without your computer, and you needed to do
the 2nd connect from a windows machine. or your palm pilot. or any
web browser that supports java (another feature of vnc is that it has
a java connector that works entirely in a browser).
vnc's x server is very low-resource compared to an actual x server,
and so yes, there is some memory usage overhead, but it is just about
negligible since you don't have to run a second window manager, etc--i
used to run vncserver on a 200mhz handheld sharp zaurus with something
like 64MB ram and using it for remote access at the same time as i was
using the zaurus interactively on console caused no slowdown for the
console user. i imagine that any tablet being manufactured today
could handle it without blinking, and i imagine them to be the most
cpu-starved situation you might exist in today. (says the fellow who
still runs a fanless 1ghz via fileserver with 256MB of memory).
ultravnc offers a wide array of compression options to best serve
whatever kind of remote connection you have. it's gpl'ed.
perhaps i am still missing the point and this doesn't solve your
problem. if so, please explain what you are *actually trying to do*
instead of providing hypothetical examples so the next hour i spend
coming up with a solution can be useful to you =)
if i missed, please include in your proposed actual implementation a
list of gotchas like "stream must be encrypted" (tunnel vnc over ssh),
or "no my application really does understand two cursors and keyboard
input streams and uses them in manner X" (and explicitly list the xwin
api's or extensions that it uses to do so).
> Remember, X already does something
> like this with single display servers, so duplicating the X
> message stream to two display servers is not inherently difficult.
i agree, the concept seems simple. i suspect creating the
implementation is more hairy than we suspect, versus using an existing
tool that provides functional equivalence. but hey, if you're gonna
roll your own...vnc's source code is probably a good place to start
looking =)
luck++;
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
