mo@prisma.UUCP (Mike O'Dell) (09/04/88)
There has been a lot of conversation about "Has X Won the Window Wars?" I can't understand why supposedly technically-minded people INSIST on talking about winners and losers. No window system on UNIX has anything remotely like the software available on the Macintosh, so if you are inclined to use "market choice" as your yardstick, THEY ALL LOSE. Clearly, no Unix devote' likes this bit of fact, so we gotta argue over other things. I understand the problem - people want to go off and implement software, but want to make sure they pick "the right one." Sorry, the world doesn't accomodate such things. There is no "right one" simply because they all have serious problems. A few examples, not to pick on anyone in particular (1) X is a way to do device-dependent graphics across a network - changing screen resolution screws the application. This doesn't happen with NeWS. There is also the toolkit issue. (2) NeWS suffers from needing two programming languages, one worse than most assemblers. This could change soon, however. It is still complex but flexible. NeWS needs a toolkit, too. (3) WINDOW SYSTEMS DON'T MATTER. It is the consistency of the look and feel of ALL applications that matters. NOTHING is worse than having 5 applications up on your bottle and each one looks and acts differently. Don't try claiming this ain't happening, 'cause it is. Until this is addressed, you are asking the wrong questions when you mutter about window system choices. (4) Open Look is coming. This will be a powerful force since it will be implemented on both X and NeWS, obviating the issue of which window system you write for (assuming the Open Look toolkit designers do a good job). Open Look will not be the answer to Life, the Universe, and Everything, but it will make it possible to write quality visual software for Unix that will run on more than one platform; something that is largely impossible at the moment. My opinions are my own. Noone else would want them. -Mike O'Dell
bzs@encore.UUCP (Barry Shein) (09/05/88)
From: mo@prisma.UUCP (Mike O'Dell) >(1) X is a way to do device-dependent graphics across a network - > changing screen resolution screws the application. > This doesn't happen with NeWS. There is also the toolkit issue. I've been thinking about this and wonder if X has received too bad a rap on this issue. To some extent this is an observation that the X primitives are at a lower layer than NeWS primitives (ie. NeWS certainly at some point translates to screen coordinates, it's just that that layer is not generally visible.) The only real weakness in X on this count (and it's serious) is the lack of scaled font machinery in the server. If that were there then device independant graphics could be left to the toolkits. I suppose the whole geometry thing has to go out the window (so to speak) also, encouraging things like =200x400 anywhere is a wrong thought (although applications like xterm take it in row/columns which is just fine.) That needs more thinking although the answer will be simple (one obvious solution is to go for a troff'like notion of units, 2ix4i means 2 by 4 inches, 200px400p means 200 by 400 points etc, basically trivia to implement, unlike the font machinery stuff which is hard.) Proof: Crispin Goswell's postscript interpreter runs just fine under X (it even has its own scaled font machinery which is not the place for it, but it does work, given support in the server it could be moved out.) I also have a half-written X toolkit which uses arbitrary units for specifying all sizes, scaled fonts were the big bugaboo that have slowed me down. X servers are happy to return the size of the screen in inches and the number of pixels available in each direction (and pixel depth), once that's queried the toolkit can appear device independant. So the real misunderstanding is the level at which X and NeWS sit. X is a remote device manager to a great extent, NeWS more resembles a toolkit which might sit above something like an X (Goswell's ps interpreter comes so close to this that it's hard to deny outright.) Other than that I think Mike is right on the mark here, abstracting to a look and feel will resolve the issue to a great extent. In fact, I believe my comments above strengthen Mike's points, people are probably asking the wrong question. -Barry Shein, ||Encore||
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (09/06/88)
In article <8809021443.AA12775@uunet.UU.NET> mo@prisma.UUCP (Mike O'Dell) writes: | |There has been a lot of conversation about "Has X Won the Window Wars?" | |I can't understand why supposedly technically-minded people INSIST on |talking about winners and losers. No window system on UNIX has anything |remotely like the software available on the Macintosh, so if you are |inclined to use "market choice" as your yardstick, THEY ALL LOSE. I can't believe you have so completely missed the point. First of all, I express doubt that any software package on the Mac can compete with the several packages we purchased for our Unix workstations. (One package costs more than $50,000). Second, if you had to develop a large complex application you want running on as broad a base a possible, which window system would you choose to spend all of you effort in? Us technically-minded people aren't *using* the packages on current window systems, but *developing* packages for future window systems. Look and feel are important issues, sure. But if you had to start writing code tomorrow, you would have to make a decision. Now. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
mh@wlbr.EATON.COM (Mike Hoegeman) (09/07/88)
In article <8809021443.AA12775@uunet.UU.NET> mo@prisma.UUCP (Mike O'Dell) writes: > .etc.... >the world doesn't accomodate such things. There is no "right one" >simply because they all have serious problems. A few examples, >not to pick on anyone in particular > .etc... > >(2) NeWS suffers from needing two programming languages, one worse than > most assemblers. This could change soon, however. > It is still complex but flexible. NeWS needs a toolkit, too. Classifying PostScript as "worse than most assemblers" is inane at best. Have you ever programmed in postscript for more than a day?. If you have, my apologies. I'll take your opinion at face value. If you have'nt then please don't make such cavalier statements. Where I work one person was really afraid of the prospect of having to write PostScript code. Once they got into it though THEY PREFERRED IT TO WRITING C CODE !!!. I myself write in PostScript and C daily and have no problems switching between the two. It's really not that big of a deal and the power you get with PostScript makes it well worth the trouble it takes (which is no worse than C in my opinion) to learn it. In short don't knock it till you've tried it. -mike
msc@canth.SGI.COM (Mark Callow) (09/09/88)
In article <3562@encore.UUCP>, bzs@encore.UUCP (Barry Shein) writes: > > From: mo@prisma.UUCP (Mike O'Dell) > >(1) X is a way to do device-dependent graphics across a network - > > changing screen resolution screws the application. > > This doesn't happen with NeWS. There is also the toolkit issue. > > I've been thinking about this and wonder if X has received too bad a > > The only real weakness in X on this count (and it's serious) is the > lack of scaled font machinery in the server. If that were there then > device independant graphics could be left to the toolkits. Barry greatly oversimplifies the problem. Having the window server deal only in screen-coordinates presents two major problems: 1. It places a huge burden clients (i.e. application programmers) that wish to be device independent and to change size to fill their windows after a resize. Most clients want to do this. 2. It makes it impossible to use transformation hardware to support the rather basic operations mentioned above. Transformation hardware can only be used by providing extensions that give different imaging models or by allowing the client to bypass the X server and draw to the hardware directly. If the server handles the transformations the client writers job is greatly simplified and transformation hardware can be used. Transformation hardware is going to become much more common in the next few years and people are naturally going to want to use it. It will be an awful shame if the window system bars all standard clients from access to that hardware. Geometry is a giant leap ahead of pixels. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."