mouse@thunder.mcrcim.mcgill.edu (der Mouse) (04/14/91)
In article <128236@uunet.UU.NET>, rbj@uunet.UU.NET (Root Boy Jim) writes: [...X...] >> was painfully slow, quite a pain to program, and binaries linked to > That's part of it. But the real problem is that it's too difficult to > program. You can't possibly remember all those include files, > arguments, and function calls. You'll need a whole shelf of manuals > to write the simplest code. Speak for yourself. I need only one manual, and I keep it in a file (it's only about .75 MB). And I don't refer to it all that often anyway. > Device independence? Hogwash! Unlike NeWS, the interpreter is in > the wrong place. Partially agreed. For many applications the ability to download code into the server would be a major win; the real problem is that the resulting system is much heavier weight. (If you don't agree, where are all the NeWS-terminals? X-terminals are selling left and right.) > Yeah the server swaps bytes, but the client must use the server's > pixel sizes, colormaps, etc. This is orthogonal to your previous sentence. X made the right choice when they specified all coordinates in terms of pixels: until pixels are too small to see, you don't want a pixel-independent protocol language. (Which is one reason I don't like PostScript-only printers.) As for colormaps, what's your point? The client has control over the contents of the colormap; what more do you want? (Unless the hardware doesn't have dynamic colormaps, in which case you obviously can't get it, or the server is exceptionally brain-damaged, and deliberately stupid software can be cited on both sides of any argument like this.) This is moving away from UNIX into X, so I'm moving it from comp.unix.wizards to comp.windows.x. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rbj@uunet.UU.NET (Root Boy Jim) (04/16/91)
In article <1991Apr14.084432.11937@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: ?In article <128236@uunet.UU.NET>, rbj@uunet.UU.NET (Root Boy Jim) writes: ?> Device independence? Hogwash! Unlike NeWS, the interpreter is in ?> the wrong place. ? ?Partially agreed. For many applications the ability to download code ?into the server would be a major win; the real problem is that the ?resulting system is much heavier weight. (If you don't agree, where ?are all the NeWS-terminals? X-terminals are selling left and right.) We all know why. Because Sun didn't push it the way they did with NFS. And because the other vendors were leery of Sun after NFS. ?> Yeah the server swaps bytes, but the client must use the server's ?> pixel sizes, colormaps, etc. ? ?This is orthogonal to your previous sentence. X made the right choice ?when they specified all coordinates in terms of pixels: until pixels ?are too small to see, you don't want a pixel-independent protocol ?language. (Which is one reason I don't like PostScript-only printers.) I don't think so. Forcing the client to think in terms of the server's pixel dimensions is tyranny. It also precludes use of graphics accelerators that may be resident on the server because the client can't possibly understand them. ?As for colormaps, what's your point? The client has control over the ?contents of the colormap; what more do you want? (Unless the hardware ?doesn't have dynamic colormaps, in which case you obviously can't get ?it, or the server is exceptionally brain-damaged, and deliberately ?stupid software can be cited on both sides of any argument like this.) I don't want to have to worry about colormaps. I just want to draw in color. Let the server do the best it can. I want the client to be able to say what it wants to do in the most general terms, and for the server to fill in the blanks. ?This is moving away from UNIX into X, so I'm moving it from ?comp.unix.wizards to comp.windows.x. I'm moving it back, cuz I don't read comp.windows.x. Besides, there's little competition here :-) -- [rbj@uunet 1] stty sane unknown mode: sane
kenney@milton.u.washington.edu (Michael Kenney) (04/17/91)
In article <129127@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > >I'm moving it back, cuz I don't read comp.windows.x. >Besides, there's little competition here :-) >-- ENOUGH ALREADY! For better or worse, X is here to stay - If you don't like it *don't use it*. > [rbj@uunet 1] stty sane > unknown mode: sane Mike Kenney UW Applied Physics Lab