Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!granite.pa.dec.com!mellon From: mellon@nigiri.pa.dec.com (Ted Lemon) Newsgroups: comp.unix.ultrix Subject: Re: Ultrix 4.2 Message-ID: Date: 20 Jun 91 01:49:57 GMT References: <1991Jun17.142547.4691@searchtech.com> <14411@dog.ee.lbl.gov> <984@lhdsy1.chevron.com> Sender: news@pa.dec.com (News) Organization: Digital Equipment Corporation Lines: 46 In-Reply-To: yzarn@lhdsy1.chevron.com's message of 19 Jun 91 20:54:01 GMT In article <984@lhdsy1.chevron.com> yzarn@lhdsy1.chevron.com (Philip Yzarn de Louraille) writes: >In article mellon@nigiri.pa.dec.com (Ted Lemon) writes: >> >>without it. Plus, the MIT server doesn't do multiscreen. > C'mon! Do you think the DEC server does multi-screen? It really does > not, it emulates multi-screen! > You need to run a window manager per screen you are using and you cannot > move a window from one window to another. I do not call this a > multi-screen server, not by a long shot, especially after seeing a > *real* multi-screen machine like the Mac. Actually, no. Twm, mwm and dxwm all support multi-screen displays. The reason you can't move windows from screen to screen is because the screens are considered distinct by the X protocol - an application can't be told through the X protocol that it should free all its resources and reallocate them on a new screen, and there's no clean way to do that freeing and reallocation process anyway. It would be possible to implement an X server that considered multiple physical screens to be the same virtual screen, but there are problems with this. For one thing, in order to avoid violating the X protocol specification, you would have to make the colormaps on both screens identical. This would mean that an application on one screen changing the colormap would affect applications on the other screen. Another problem is that you can theoretically support frame buffers with different depths, and the X protocol doesn't define any way to say that a certain portion of a screen is monochrome, while another portion is colour. That said, I agree that it would be nice to have the choice between the current implementation and some version of the implementation that I described above, where you are constrained to using frame buffers of the same depth, and where such frame buffers have their colour tables kept in sync. I had heard at one point that an MIT grad student was hacking such a server, but I haven't heard anything about it for quite some time. Finally, this doesn't seem like a good excuse for DEC-bashing. At least we support the form of multiscreen that the X protocol is most receptive to. Many of our competitors do not. The current X Consortium release does not. If you want to bash DEC, I'm sure you can come up with something much more compelling - plenty of other people on this newsgroup have been successful at it in the past. :') _MelloN_