X is/isn't faulty (was Ware Ware Wizardjin)

[der Mouse]

In article <128236 at uunet.UU.NET>, rbj at 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 at larry.mcrcim.mcgill.edu