wayne@dsndata.uucp (Wayne Schlitt) (06/29/88)
I have been following both the news and x news groups for a fair while now and lately i have noticed that there is about ten times the traffic in the x news group. are there that many more people developing under x than news, or is the volume just skewed by all the universities on the net? our company has a specialized cad package that we will eventually port to run under either news, x, or what ever becomes the standard. it will be about a year before we are ready to start, so for now i am just watching both groups, trying to pick up all the info i can get. -- Wayne Schlitt | Design Data Corporation hplabs!hpfcla ----------\ | 1033 "O" St. Suite 324 ncar!handel!hpfcla ------>---> !dsndata!wayne | Lincoln Ne, 68508 ihnp4!upba -------------/ | (402) 476-8278
benoni@ssc-vax.UUCP (Charles L Ditzel) (07/03/88)
in article <WAYNE.88Jun29195537@dsndata.uucp>, wayne@dsndata.uucp (Wayne Schlitt) says: > I have been following both the news and x news groups for a fair while > now and lately i have noticed that there is about ten times the traffic > in the x news group. are there that many more people developing under > x than news, or is the volume just skewed by all the universities on > the net? A couple of thoughts : 1) X has a fairly significant lead on NeWS at the moment. You have to take into consideration that NeWS is only just starting to come out for systems such as the Macintosh and has yet to come out for PCs. However, Silicon Graphics has just released a window management system that includes NeWS. It is a NeWS/X window manager called 4sight (or something like that). Other computer vendors are also working on ports...Sun itself will shortly be coming out with its supported NeWS/X port...SCO is reportedly going to have NeWS/X for their Xenix systems... 2) The next questions are : what is the staying power of X given NeWS' availability on similar platforms? Will the future simply be NeWS/X window managers or just one or the other? I don't think too many people are arguing that X11 is technically better ... rather more people tend to argue the reverse (surprisingly even some of the X folks concede the point) ... > our company has a specialized cad package that we will eventually port > to run under either news, x, or what ever becomes the standard. it Actually the next year should be alot of fun to watch... there will be alot products out for X...NeWS action should be picking up in intensity also ... as it is supposedly included with Release 4 of Unix...new vendors should emerge. NeWS products should also be forthcoming...(recently Sun announced it's first NeWS product - SNA 327? emulation) The recent schisms in the Unix world will make all this even more interesting... One more note : I tend to think that those companies that offer both systems are in a much better position than those companies only offering X... ------------------ Naturally these are MY own opinions and not those of my employers.
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/05/88)
> 2) The next questions are : what is the staying power of > X given NeWS' availability on similar platforms? Will the > future simply be NeWS/X window managers or just one or the > other? I don't think too many people are arguing that X11 > is technically better ... rather more people tend to argue > the reverse (surprisingly even some of the X folks concede > the point) ... Whoa, there. Interesting that you chose to post this in a NeWS only group. In an X group, I'm sure you'd get quite a bit of disagreement on this. Before I begin, let me say that I'm in the X camp myself (I'm an experienced X programmer, have seen NeWS and believe I understand the basic model, but am not a NeWS programmer, so feel free to correct any technical errors regarding NeWS -- which I'm sure you would even without an invitation :-) Both NeWS and X have technical advantages, but I don't believe one is fundamentally superior to the other. However, X has from the beginning, been a completely open system, whereas NeWS has been an expensive, licensed piece of software until the introduction of the AT&T NeWS distribution. Now that NeWS will be more freely available, NeWS and X can compete on equal footing. Until now, it was a simple choice: do you want a proprietary system which one vendor is trying to foist on the world (NeWS) or a multi-vendor, open system, which has been freely available from the very start (X). NeWS advantages over X: high power imaging model (2D) using absolute dimensions, rather than pixels non-rectangular windows Postscript available Toolkits can be interpreted in the server, and thus substituted out from under the application mimimal traffic between client and server disadvantages of NeWS relative to X: requires relatively powerful NeWS server -- a NeWS terminal will be more expensive than an X terminal programming process context switching and partitioning between client and server is a PAIN for the progammer. programming in Postscript is a pain (of course, Sun provides a C translator so this isn't that big a problem). Now, let's examine the NeWS advantages for a moment and see how important they are. Regarding the imaging model, it is only 2D, and X is getting the 3D graphics extensions defined as a standard extensions, so any vendor with good hardware for graphics will probably support it. The issue of absolute dimensions and font scaling is a real one, though, of course, there are workarounds in a pixel based system (adjusting depending on the screen size). Non-rectangular windows is "gee whiz," but frankly, I don't care about that at all. Other than having round clocks, I just don't see this as a big deal. Postscript will be available on X as well, thanks to Display Postscript and some public Postscript previewers. (please note my distinction of the imaging model and just having Postscript -- this item addresses the display of Postscript and the output language only) The ability to have interpretive toolkits which can be swapped is useful, but there are other ways to accomplish this in X as well (using dynamic loading, for instance). Probably the most significant difference between X and NeWS is the traffic between client and server. First of all, Scheifler wrote a paper about why the traffic breakdown wouldn't be as good as the claims (because the communication for even simple operations like menus would be higher than expected). Second of all, it doesn't really matter! I'm a network administrator and I have some experience on this subject. Lan bandwidth is rarely the bottleneck in communications between two machines. We run diskless (including remote swap), remote X, etc. and the volume of traffic is just never that high (typically under 5% of lan utilization). Also, most X servers run with Unix Domain sockets when running locally, so lan overhead isn't a big issue. The only issue that remains is the performance in terms of throughput on the lan. We are already at the point where lan performance is within the same ballpark as disk transfer rates, so it isn't that big a deal, and we're getting faster lan technology too. The only time this will really matter is for non-local lans, like SLIP remote links or over low-speed remote channels. In that case, I concede that NeWS has an advantage, but that is probably only a small percent of the use of either NeWS or X, and running at 9600 baud over SLIP for X will still be acceptable, I believe. Basically, the assumptions that X used were that a high-speed byte stream was available between client and server and that the client was a more powerful machine than the display server. NeWS uses a different set of assumptions (or at least it shines in a different environment). NeWS is best when the link speed is low and the client and server are roughly the same power. That means if you have a Sun workstations at home, then you are probably best off running NeWS remotely, but if you have a PC or a custom window terminal at your desk, you're better off running X. > One more note : I tend to think that those companies that > offer both systems are in a much better position than those > companies only offering X... This is probably true, at least until things settle out. Disclaimer: These opinions are my own and do not necessarily reflect those of Hewlett-Packard. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
hvr%kimba@Sun.COM (Heather Rose) (07/06/88)
In article <WAYNE.88Jun29195537@dsndata.uucp> wayne@dsndata.uucp (Wayne Schlitt) writes: >I have been following both the news and x news groups for a fair while >now and lately i have noticed that there is about ten times the traffic >in the x news group. are there that many more people developing under >x than news, or is the volume just skewed by all the universities on >the net? From what I hear from customers, NeWS is confusing at first. Just like C was confusing at first, just like UNIX was confusing at first. It takes a while to get used to programming in a stack based language (Postscript). It takes time to understand classes. But the benefits it provides are worth it to me. Besides, I like HP calculators ;-) >our company has a specialized cad package that we will eventually port >to run under either news, x, or what ever becomes the standard. it >will be about a year before we are ready to start, so for now i am >just watching both groups, trying to pick up all the info i can get. Try them out. Only you know what is best for your application. See what NeWS can do versus what X11 can do. You will most likely run into limitations with both systems, so choose the one that is most cost effective. If you're serious about investigating these systems, take some educational classes. Apollo offers one on X, Sun on NeWS. It's all well and good to read about what others are doing, but you really won't know until you try to get some WORK[tm] done with either system. And, writing a CAD package seems to be alot of WORK[tm] to me. Another big issue to me would seem to be 3-D support if you need it. How do the windowing systems deal with that? or do you have your own, how does the windowing system interface with your routines? What about other medium like video? Input from different types of devices like drawing pads, scanners? How is that handled? If you want the scoop on when products will be out etc for Sun, your local Sun salesrep is your best bet. --Heather Rose
elwell@ichthyosaur.cis.ohio-state.edu (Clayton M. Elwell) (07/07/88)
diamant@hpfclp.SDE.HP.COM (John Diamant) writes:
Before I begin, let me say that I'm in the X camp myself (I'm an
experienced X programmer, have seen NeWS and believe I understand
the basic model, but am not a NeWS programmer, so feel free to
correct any technical errors regarding NeWS -- which I'm sure you
would even without an invitation :-)
Well, I'm in the NeWS camp. I've used X a lot, but for programming
I've been using NeWS (I gave up on X after the third try...). I
understand X pretty well, although I'm sure you (or, in fact my
coworkers) will correct me if I get confused :-).
Both NeWS and X have technical advantages, but I don't believe one is
fundamentally superior to the other.
Well, part of the difference between them, and part of why it's hard
to compare them, is that they are based on very different ideas of
"what a window system should be," and so some of the issues are more
religious than technical.
One, for example, is the whole issue of PostScript. I actually don't
find PostScript any more obtuse to program in than C, and with the
class system that Sun provides as part of NeWS, doing user-interface
type stuff is in fact a lot easier. Of course, I also find my HP
calculator perfectly easy to use :-).
Now, let's examine the NeWS advantages for a moment and see how
important they are. Regarding the imaging model, it is only 2D,
and X is getting the 3D graphics extensions defined as a standard
extensions, [...]
I think this a straw man argument.
Most workstation displays I've seen are 2D... Yeah, you can add
3D rendering primitives to X, but I can add 3D rendering operators to
NeWS, without (a) having to touch my binaries or (b) making
assumptions about the display itself. If I'm a vendor, I can even
hack my version of the server to do it in hardware.
Non-rectangular windows is "gee whiz," but frankly, I don't care
about that at all.
Well, it's not just windows. Anything can be non-rectangular. Like
buttons and controls. I agree that rectangular ones are good enough
for most simple interfaces, but it's nice to have the generality there
when you need it.
Postscript will be available on X as well, thanks to Display
Postscript and some public Postscript previewers.
And Display PostScript is evidently very nice and fast. However,
previewing PostScript documents is a small portion of what I do with
my workstation. PostScript itself isn't so much the issue as having a
well-defined way to extend the capabilities of the display server, on
the fly if necessary. The simplest way to do this is to pick a simple
language with good graphics primitives. Add popular to the
requirement, and PostScript seems the logical choice to me. I'd
rather that than Interpress or HPGL :-).
The ability to have interpretive toolkits which can be swapped is
useful, but there are other ways to accomplish this in X as well
(using dynamic loading, for instance).
Of course, dynamic loading is done differently on every flavor of
UNIX, so the client support routines have to be kept up to date. With
NeWS, all you have to do is be able to talk to your display, which is
kind of a given.
Probably the most significant difference between X and NeWS is the
traffic between client and server. First of all, Scheifler wrote
a paper about why the traffic breakdown wouldn't be as good as the
claims (because the communication for even simple operations like
menus would be higher than expected).
Well, in most of the programs I've seen, most menu choices either
*don't send anything back to the client at all*, or send a byte as
part of the input stream. Seems pretty low overhead to me. But
that's probably not a good example.
Second of all, it doesn't really matter!
I like that--the most significant difference doesn't really matter!
The only time this will really matter is for non-local lans, like
SLIP remote links or over low-speed remote channels.
Which, of course, nobody ever really uses... Take the ARPAnet, for
example... :-).
Basically, the assumptions that X used were that a high-speed byte
stream was available between client and server and that the client
was a more powerful machine than the display server. NeWS uses a
different set of assumptions (or at least it shines in a different
environment).
I'd say that NeWS is based on the display server knowing about the
details of the display hardware, so that the client didn't have to
worry about it, and that abstraction is a good thing. X is one of the
least abstract systems I've ever used. I like Bill Joy's
description--"rasterop on wheels". I like PostScript on a window
system for the same reason I like it on a printer or a typesetter.
Most of the time, I don't want to have to worry about how to chisel
bits onto the screen. I realize that things like Xtk and so on help,
but still, it's a virtual display at a lower level than I care to deal
with.
Clayton M. Elwell <elwell@tut.cis.ohio-state.edu>
Ohio State University CIS Dept. Research Computing Facility
"... there was a *third* possibility that we hadn't even counted
upon ..." --Arlo Guthrie, "Alice's Restaurant"bzs@bu-cs.BU.EDU (Barry Shein) (07/07/88)
Hi, my name is Barry Shein and I am an alc...no, that's not right... I am not and never have been a card carrying member of...ummm, one more time... I'm trying to be very open-minded on the X/NeWS issue. This means I've probably pissed off both camps sufficiently and they are each quite sure I lean the other way, as religions are wont to do (see for example the writings of Cardinal Newman, "one cannot be both a believer and questioner"), relgions are usually more open to identifying heretics than observants... First, I have vastly more experience with X than NeWS tho I don't think I misunderstand NeWS, I think I get the point. I am very sensitive to the "imaging model" issue. One of the first things anyone attempting to write a toolbox in X runs into (at least any honest person) is the whole issue of pixel sizes and relative metrics, particularly with fonts, big problem with X, claims of "portability" seem to slip away when they can't even abstract the bit density of the screen away from the programmer (reminiscent of the old IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 bytes/track on a 3330 you fool!!!") For example, I was just writing an X11 widget which is a general purpose "meter", something with marked points and hands etc. If you resize the meter there's no problem redrawing the hash marks or hands to conform nicely, but what to do about the fonts?? (eg. markings around the edge), not much except guess that some other font size *might* now be appropriate, sort of, using some threshold calculation (and hope that size is available in this server etc.) Generalized text can be even worse and the whole model (X) lends itself to such absurdities as distributing one bitmap font set on the tape (ludicrous! these are 84 dpi fonts and I'm on a 91 dpi screen, that's enough to make kerning etc just look wrong (and forget things like Hi-res monitors) and was my motivation for writing "gfto" which at least lets you regen fonts for your screen dpi, tho that only addresses part of the problem.) On the other hand, there it is (X), and it basically works quite well AS ADVERTISED and fits a model of subroutine access nicely enough (although object data management in C is less than wholesome, I'm not sure that mere Postscript can quite address that although an object oriented approach helps, at any rate, that's not *obviously* a fault of X but might be a sin of omission.) But NeWS seems to solve the imaging problem trivially (while creating others, like who the heck *wants* to program in postscript other than Don Hopkins :-) Why couldn't the whole remote interpreter thing (in re X) be more or less resolved by judicious use of the "rsh" command? Aren't window handles global? So why not something like: sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); system(buf); Sure, that's a little slow because you have to authenticate on each command but opening a socket to a remote shell or using something like rexec/rexd/rpc directly could solve that (you get the idea.) Forking has some overhead, is it important? I dunno, Unix sez no, not in general and this case would tend to weigh in its favor (if the thing was so short-lived that fork/exec is a major factor then you may as well have computed that on the client, that's another problem, *someone* has to make all these decisions.) It does mean you'd have to compile (with its disadvantage of either needing to make the decision beforehand or incurring the delay of compiling some rcp'd code, with the advantage of course that it would now be compiled/optimized, again assuming we bothered because it was too expensive to do on the client so cost is a relative thing and run-time speed is important ultimately.) Shared libraries of course help the disk space and loading time issue etc. Don't talk to me about dynamically loaded C object decks, I've had too much blood run out of my eyes porting those beasts and until someone puts that into OS's universally I say forget it except in special cases, and whoever puts it into the system should be obliged to write the routine needed for every OS that's requested, forever. It doesn't even port between minor OS releases in most cases. Similarly one could easily imagine opening a socket to a lisp which has CLX (Common Lisp X) pre-loaded and passing lisp structs much as above (I know, all together, "lisp is a memory pig", is postscript lightweight on memory? is this still a critical issue to most people? actually lisp doesn't have to be that much of a memory pig, that's an old wives tale borne mostly of non-paged 64KB/256KW machines.) My prediction? (hmm, maybe shoulda included comp.society.futures) That something else will come along in the next coupla years making both X and NeWS obsolete, if I knew what it was I'd go ahead and implement it, make a coupla billion and leave the rest of y'all in the dust :-) Don't confuse good ideas with mediocre implementations (there, good, I pissed off everyone *again*.) -Barry Shein, Boston University
matheny@Unisyn.COM (John Matheny) (07/07/88)
As an application developer, these are some of the attributes that I considered when evaluating the X Window System and NeWS: Portability. I want to minimize the amount of effort it takes to port applications from one platform to another. Therefore, I want to use a window system that exists on all of platforms in which I am interested. The X Window System seems to have an upper hand in this at the moment. However, I believe that this may change when X.11/NeWS is in UNIX V.4 and when vendors stop telling and start listening to their customers who understand the issues. Device independence. I want the window system to insulate my applications from having to know about the basic characteristics of the display device: output resolution, bit-mapped displays versus printers, keyboard mapping, pointing devices, color availability, etc. This lets me spend more time concentrating on the functionality of my application rather than its environment. The PostScript imaging model in NeWS supports this very well; the X Window System does not. Performance in a network environment. I want my application's user interface to perform well in a wide variety of configurations: same machine, machines separated by a high-speed LAN, machines separated by a phone line. Therefore, I want the flexibility of putting all or part of my application's user interface, both input- and output- related components, close to the user where it can be the most responsive. If I use NeWS I have that flexibility. With the X Window System I am stuck with everything residing on the client. I believe that dynamic server programmability, whether it is a window system server, a compute server, or a database management server, is a key to performance. Development environment. I want the window system to include tools and/or techniques that facilitate software development. I have found that all of the functions and their arguments in the X Window System and toolkits to be at least as compilicated of a "language" to learn than the equivalent in PostScript/NeWS. I was able to become proficient in PostScript/NeWS in a very short amount of time and found a number of features that make it very attractive: it has an interpreter that I can type to and get immediate feedback; it lets me do "late binding" of variables and even functions, making my software both more simple and more general; both the input model and the output model are wonderfully flexible; and the object-oriented programming features of NeWS keep my software organized, well-structured, and extensible. I haven't had any difficulty in switching between C-based application programming and NeWS-based user interface programming. In summary, NeWS meets my window system requirements much better than the X Window System. NeWS offers a programmable server for dynamic extensibility and superior performance in a network environment, features a very powerful stencil/paint graphics model that is device- and resolution-independent, and facilitates development with an interactive, object-oriented environment. All of these are features that I want when building state-of-the-art application user interfaces. -- John Matheny Internet: matheny@Unisyn.COM UUCP: uunet!unisyn!matheny Unisyn, Inc., 3300 Mitchell Lane, Boulder, CO 80301 +1 303 443 7878
carlson@aftac.tis.llnl.gov (John Carlson) (07/07/88)
In article <23656@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >I am very sensitive to the "imaging model" issue. One of the first >things anyone attempting to write a toolbox in X runs into (at least >any honest person) is the whole issue of pixel sizes and relative >metrics, particularly with fonts, big problem with X, claims of >"portability" seem to slip away when they can't even abstract the bit >density of the screen away from the programmer (reminiscent of the old >IBM/JCL decks I've had to debug, "no no no, you can't specify 8000 >bytes/track on a 3330 you fool!!!") Ideally I could scroll my display around a large root window. Call it a virtual windowing system (swap and page rectangles?). Also, I may want to zoom in on a particular window, if it is a graphics display, or if the text is too small to read. >Why couldn't the whole remote interpreter thing (in re X) be >more or less resolved by judicious use of the "rsh" command? >Aren't window handles global? So why not something like: > > sprintf(buf,"rsh %s Xfrob -wid 0x%x", HOST, WINDOWID); > system(buf); > >Sure, that's a little slow because you have to authenticate on each >command but opening a socket to a remote shell or using something like >rexec/rexd/rpc directly could solve that (you get the idea.) Using rsh in a window system is like using rcp in a file system. We should be able to share windows between servers (hosts). What I type in a window on my display/screen will appear in the same window on your display/screen without the application knowing! I would like to move a window from my display/screen to your display/screen with my window manager assuming permissions are OK. [ I think HP did something like this with X11 ] >Similarly one could easily imagine opening a socket to a lisp which >has CLX (Common Lisp X) pre-loaded and passing lisp structs much as >above (I know, all together, "lisp is a memory pig", is postscript >lightweight on memory? is this still a critical issue to most people? >actually lisp doesn't have to be that much of a memory pig, that's an >old wives tale borne mostly of non-paged 64KB/256KW machines.) I would prefer some kind of interpreter. Take your choice between X10, X11, Lisp, PostScript, NeWS, ANSI C, Smalltalk, or next year's language. Also, I should be able to mount local window hierarchies and EXISTING remote window hierarchies on my root window wherever I like. [ Some of this can be done under NeWS and X11 ] >My prediction? (hmm, maybe shoulda included comp.society.futures) > >That something else will come along in the next coupla years making >both X and NeWS obsolete, if I knew what it was I'd go ahead and >implement it, make a coupla billion and leave the rest of y'all in the >dust :-) Drop a few million my way. I won't mind. "These aren't my ideas, they are old ideas rehashed." John Carlson
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (07/07/88)
In article <10250002@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Non-rectangular windows is "gee whiz," but frankly, I don't care about that >at all. Other than having round clocks, I just don't see this as a big deal. Isn't there some famous quote from a few years ago of Tom Watson saying that all the world would only need about eight computers? The amazing thing is, even with that tradition of foresight, his company is still selling computers. There may be a future for window systems that don't support arbitrarily-shaped objects, after all. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob
klee@daisy.UUCP (Ken Lee) (07/08/88)
There seem to be at least 2 very different sets of workstation users out
there. Each has very different needs.
Academic users tend to write small, interesting programs. For them,
NeWS is superior because it is more elegant and theoretically powerful.
Note that Sun only had to add a small number of features to graft X onto
the NeWS server for the X/NeWS merge. Adding NeWS to an X server would
have been a major overhaul. See the paper in the last USENIX
proceedings for details.
Industrial users, like myself, prefer X. It is much more complete
(e.g., lots of toolkits and window managers), more robust, and, most
importantly, is (or soon will be) available for almost every engineering
workstation. All the manufacturers are supporting X to some degree.
We do lose some functionality, but X is more than powerful enough for
most current applications programs.
The competition between the 2 systems is, of course, good. Future
window systems will include the best features from both (if the lawyers
don't interfere). The X/NeWS merge is still too kludgey for most
people, but it may mature into a very nice system. Stay tuned.
Ken
--
uucp: {atari, nsc, pyramid, imagen, uunet}!daisy!klee
arpanet: atari!daisy!klee@ames.arc.nasa.gov
STOP CONTRA AID - BOYCOTT COCAINEbarnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (07/08/88)
In article <10250002@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >Non-rectangular windows is "gee whiz," but frankly, I don't care about that >at all. Other than having round clocks, I just don't see this as a big deal. Perhaps you should think of objects instead of windows. I can see it useful to have icons change shape and size according to function. The fat trashcan on the Mac is an example. There is an lpqtool from sunspots ( see Chuck Musciano's tooltool) that can be opened to examine the queue. Perhaps the icon's image could change to a LaserWriter with the lid open when the queue was jammed. However, this would be ugly with a rectangular area for an icon. I would like the L-shape of this icon to have an L-shape clipping area on the root menu. In fact, with my constant battle of real estate, I would like a more flexible organization of icons. Icons arranged like a tree, a Rolodex, or a jigsaw might be useful at times. The new garden demo has an icon the shape of a flower! I would like to display a complex system with an assortment of connectors, dials, pipes, ducts, boxes, etc. (DataViews does this). Pipes that change color, texture or size can provide better feedback than simple lines with labels. This seems to be a natural use of NeWS. (This could be done with X, I am sure. But the effort would be much higher - I would guess.) If you look at HyperText systems, or packages like FileVision on the Mac, combining non-rectangular images can be much more useful. I don't think the potential of a NeWS environment has been demonstrated yet. We have been given a taste, but the Real System hasn't been demonstrated yet. I have had a couple of ideas that seem possible with NeWS, and difficult with any other window system. Perhaps some enterprising developer would like to implement these ideas: 1). Our LaserWriters frequently print screendumps. This is a real drag. I would like to take any window and print it. Because of the PostScript model, this should be easy to do, and improve printer thruput and quality. 2). I often work on several projects at once. With all of the interruptions I get, I would like to take the current window environment, and shrink the entire window to a smaller size and free up my screen for a new environment. When I want to switch back to the original environment, I would click on the miniature screen, which would change place with the current screen. This is something like the Picture in a Picture (PIP) feature of the new TV's. 3). Instead of text scrolling off the top of the window, I would like to have a "Star Wars"-like display where the text gets smaller the farther away it is from the immediate area of interest. Looking at a log file, with the older errors shrinking in size, as an example. The text would scroll off when it finally became illegible, with a user-defined lower limit. We have already seen the pie menus for NeWS. This is one example of something more radical in user interfaces. I believe this is just the tip of the iceberg. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
mike@arizona.edu (Mike Coffin) (07/09/88)
From article <WAYNE.88Jun29195537@dsndata.uucp>, by wayne@dsndata.uucp (Wayne Schlitt): > I have been following both the news and x news groups for a fair while > now and lately i have noticed that there is about ten times the traffic > in the x news group. are there that many more people developing under > x than news, or is the volume just skewed by all the universities on > the net? Another explanation occurs to me. Most of the traffic on the X news group is (a) frustrated people trying to get around questionable design decisions, (b) frustrated people trying to figure out documentation, (c) frustrated people trying to report and/or work around bugs, and (d) frustrated people trying to decide if they have found a bug. Perhaps NeWS is bug-free, well documented, and easy to understand. :-) -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
don@BRILLIG.UMD.EDU (Don Hopkins) (07/25/88)
First of all, let me point out that I think the question "Is NeWS
loosing the battle?" is totally meaningless. Right up there with
"Is NeWS tighting the war?" sic(-;
The X11/NeWS merge will be widely available as a standard part of AT&T
Unix. A battle between X and NeWS is as pointless as a battle between
VT100 escape sequences and Tektronix control codes! They're both
widely supported and emulated standards, each one best for certain
applications, and neither has destroyed the other. Terminal emulators
such as xterm support both standards, and I don't think DEC is out to
discourage people from using xterm's Tektronix features.
Date: Thu, 7 Jul 88 19:52:37 EDT
From: hpda!hp-sde!hpfcdc!hpfclp!diamant@ucbvax.Berkeley.EDU (John Diamant)
Non-rectangular windows is "gee whiz," but frankly, I don't care
about that at all. Other than having round clocks, I just don't
see this as a big deal.
Sheez, some people are so stuck in the rut of rectangular windows,
that when I tell them that NeWS has arbitrarily shaped windows,
they assume I mean arbitrary rectangles ...
Non rectangular windows are invaluable for many applications! It's
the kind of thing that once you're used to, you'll never want to do
without!
The shape of a NeWS window ("canvas") is defined by a PostScript
path. They can have lines, arcs, bezier curves, and conic splines as
edges. They can even have holes in them, and disconnected regions!
You can use either the even-odd or the zero winding rule to define
what's inside and outside the path.
The shape of a canvas influences the clipping of graphical output,
and the distribution of input events.
Each canvas has its own default coordinate system, the one that
was in effect when it was reshaped.
Canvases can be used as arbitrarily shaped targets. NeWS processes
can receive input events whenever the mouse enters, leaves, clicks,
or moves around in a canvas, and event coordinates are reported in
terms of the process's current coordinate system.
NeWS canvases are natural to use as animated "sprites", using
lightweight PostScript processes to periodically blink, move, or
paint them. (This is a great way to implement a cursor, or a space
invader!)
Transparent canvases are like opaque canvases in that they have
arbitrary shapes and coordinate systems, effecting clipping and
event distribution, except that they don't have their own image --
the image of their (first opaque) parent canvas shows through.
Graphical output on a transparent canvas gets clipped to its shape,
and drawn through into the parent's image.
A hypermedia browser that I'm porting to NeWS for Ben Shneiderman,
called HyperTIES, displays documents containing text and graphics
with "embedded menus" of links to other documents. Embedded menu
buttons are overlayed on top of text and graphics, and highlight
when you move the cursor into them.
In NeWS HyperTIES, the embedded menu buttons are simply implemented
using transparent canvases. Text buttons use canvases overlayed on
top of words in text, shaped like rounded rectangles. Graphical
buttons use canvases overlayed on top of parts of pictures, shaped
like the Hubble Space Telescope, a Faint Object Spectrograph, a
circle, a pie slice, Bill Joy's head, a rabbit, a mouse pad, or
whatever part of a picture you want to link to some document!
When the mouse moves into a button, there is some feedback to show
that it can be pressed, such as a color change, animation, or a
pop-up cut-out magnified image cookie with a shadow behind it. (Just
map a pre-fab opaque canvas with the translated and scaled image and
target shape!)
The ability to have interpretive toolkits which can be swapped is
useful, but there are other ways to accomplish this in X as well
(using dynamic loading, for instance).
There is a big difference between dynamically loaded toolkits, and
toolkits written in an interactive interpretive environment. With
NeWS, I can interactively debug PostScript code running in the
server -- looking and and changing the values of variables,
calling and redefining functions, setting breakpoints, examining
and changing the execution state of lightweight NeWS processes,
etc...
The NeWS "Lite" user interface toolkit is based on Owen Densmore's
object oriented programming package, a smooth fitting extension to
the PostScript language. With Bruce Schwartz's class browser, you
can interactively examine all the classes defined in the server.
Toolkit hacking is *easy* to do in NeWS. For HyperTIES, I extended
the NeWS "Lite" toolkit by making a Target subclass of Item, that
highlights when the mouse moves into it. I then made subclasses of
Target to do the kinds of highlighting I wanted for my application.
When HyperTIES is run, it checks to see if the Target classes are
defined in the server, and loads them in if they're not.
I can hack on the pieces of the application interface and toolkit,
reload 'em into NeWS, test them out, fix a bug, load 'em back up
and try it out again, tweak a variable, play around some more,
stick in some debugging statements, frob it until I get that funny
condition, scrutinize a broken process's state, reach inside and
redefine a function, continue the process, frob it mercilessly,
sigh in relief, and then update the source code, iteration after
iteration after iteration, all without restarting the NeWS client
or recompiling anything at all!
Probably the most significant difference between X and NeWS is the traffic
between client and server.
No, EXTENSIBILITY is the most significant difference between X and
NeWS. Low client/server traffic is just one of the many advantages
that comes from it. X is just not extensible the way NeWS is.
An X11 client can ask the server if certain predefined extensions
are available, and if they're not, the client can either give up
or do without.
NeWS extensibility is much more finer grained and application
specific -- a client can load its own extensions into the server,
teaching NeWS to communicate in whatever protocol is most convenient
for the application. It's a dynamic protocol -- clients can make
local or global extensions, on the fly! For example, when a CAD
program needs to draw a particular integrated circuit for the first
time, it could send the IC's name and a function to draw it, then
extend the protocol by associating a token with the function. From
then on, it can just send the token to draw the IC.
First of all, Scheifler wrote a paper about why the traffic
breakdown wouldn't be as good as the claims (because the
communication for even simple operations like menus would be higher
than expected).
I don't think that's true. With NeWS, all the clients share the
same menu code, which runs entirely in the server. There is no
network traffic at all involved with making a menu selection in
NeWS. The only communication that is required is informing the
client of the results of the selection (which could be as terse as
a one byte token -- who needs fixed size packets?). In many cases,
the selection can be acted upon entirely in the server!
One of the big advantages NeWS has over X in network utilization
is that for many applications, repainting a window can be handled
entirely in the server. Instead of the client responding to every
damage event (when the window is exposed or resized), it sends to
the server a program to paint the display (or a display list, and
a program to interpret it), which is executed whenever needed.
Second of all, it doesn't really matter! I'm a network
administrator and I have some experience on this subject. Lan
bandwidth is rarely the bottleneck in communications between two
machines. We run diskless (including remote swap), remote X, etc.
and the volume of traffic is just never that high (typically under
5% of lan utilization).
That sure doesn't agree with the numbers I've heard for the % of lan
utilization on nets with with diskless workstations. The way
diskless clients eat up the net severely limits the number of them
that can coexist on one piece of cable. I think network utilization
is a very important factor. I want to be able to run clients over the
Internet, and over the phone!
Also, most X servers run with Unix Domain sockets when running
locally, so lan overhead isn't a big issue.
When you run clients locally, paging and context switching become big
issues. (Are you paging over the net? Even more fun!) With X, if you
run your window manager locally, and it rubber-bands a rectangle when
you resize your window, there must be a Unix process context switch
from the server to the window manager, and back to the server, every
time you move the mouse. It's a big win to have the window manager
running in the same Unix process as the server. No frantic context
switching, and the WM does not need to keep its own copy of all those
data structures that live in the server. With NeWS, switching to a new
window manager is as easy as redefining the DefaultWindow class. With
X11/NeWS, NeWS window managers can manage X windows, too!
The only issue that remains is the performance in terms of
throughput on the lan. We are already at the point where lan
performance is within the same ballpark as disk transfer rates, so
it isn't that big a deal, and we're getting faster lan technology
too.
Disk transfer rates just don't cut it when compared to memory
transfer rates. We're getting faster and faster processors, as
well! Do you really think that advances in lan speed are going to
be able to keep up with advances in processor speed? I doubt it!
-Don
Don Hopkins
don@brillig.umd.edu
...!uunet!mimsy!don