Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!garfinkel From: garfinkel@hpfcso.FC.HP.COM (Dan Garfinkel) Newsgroups: comp.windows.x Subject: Re: Request for info on X window sharing systems Message-ID: <7320022@hpfcso.FC.HP.COM> Date: 7 Jun 91 17:26:52 GMT References: <1991May22.211831.5912@spectra.com> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 55 > Hm. I wonder how you system addresses a couple of my issues with > window sharing in X: > 1) How does it handle heterogenous visual classes? Can I run a shared > session on monochrome and color workstation simultaneously? > If so, what visual class does the shared window system present to > clients? Yes, you can share from mono to color and visa versa. SharedX takes care of translating to protocol so you can share to a display of a different visual type. SharedX will use whatever visual class the destination servers support. > 2) How does it handle window management contention? If it shares > "windows" and not "workstations" how do you avoid local copies of > the applications having dissimilar sizes? If you try to enforce the > same sizes on all copies, how do you avoid race conditions and > potential "oscillations" that cant be stopped? The only window attribute that matters to the application is size. In this case, we report the "Senders" window size to the application. If "Receivers" change their window size, information is either clipped or there is blank space in the window. If the sender changes size, that size to propagated to the receiver's windows. > 3) What about cut and paste? Does it have its own set of atoms, or > when I select something in the shared space does it snarf the selection > away from private applications on other workstations? Selections turned out to one of the hardest areas to support with SharedX by it's asynchronous nature. We didn't solve this one for our first release. When the receiver does an action which cause the selection to occur, the selection takes place on the sender's server. > 4) Floor Control? What policies are available and how are they > enforced? Each receiver of the window can either have input allowed or input disallowed. Any user with input allowed can input to the shared application. We do some amount of dynamic input locking to try to minimize intermixed keystrokes. > 5) Does it support truly multi-user applications? Are you using your > protocol extension to support applications that present different > views to different servers? No. This is not a design goal of SharedX and is not what SharedX is good at. > 6) Does it allow new users to be brought in to existing "sharings" > of windows? Can people leave and go as the please in a session? Can > I keep a "conference" going while no-one is using the software? Yes users can be added and removed at any time, under the control of the "Sender" of the window. There is really no notion of a "conference" in the user interface we provide with SharedX. -Dan