Slashdot Mirror

Yes, switching mouse hands is the way to go, and trackball (Kensington Expert Mouse) made the switch very painless. I switched over a year ago, problem solved. And in about one month my mousing ability was the same.

I also found that wrist strecthing exercises (7th picture is the best for me) work wonders at keeping the numbness away.

NeWS used PostScript throughout, as the imaging model (like DHTML), the scripting language (like JavaScript) and the data model (like XML). It was like AJAX in that it sent asynchronous messages over the network and used a dynamic scripting language on the client side (called the NeWS server), so it could implement local graphical user input feedback, and efficient application specific network protocols (using a binary encoding for PS data).

NeWS was much more consistent and better designed than AJAX's amalgamation of accidental technologies (DHTML, JavaScript, XML). NeWS also has many other advantages over AJAX, such an excellent imaging model, wysiwyg printer compatibility, shared modules, multithreading, synchronization, a programmable event distribution system, a fully developed Open Look gui toolkit, and graphical interface builder (HyperLook).

Writing NeWS PostScript is a lot like directly programming byte code for the Java or Flash virtual machines, which are both object oriented stack machines a lot like PostScript and Forth. At the time, we were well aware that many people had a hard time programming in PostScript directly (although I love it), so several interesting compilers were developed. Rehmi Post wrote a back-end to the Amsterdam Compiler Kit (CScript: C for yourself, PostScript for NeWS), Arthur van Hoff (who later wrote the Java compiler in Java) wrote PdB (Pretty darn Brilliant), a compiler that translated object oriented C into PostScript , which supported subclassing PostScript NeWS toolkit classes. Dave Singer at Schlumberger wrote LispScript, a Lisp to PostScript compiler, which allowed you to take full advantage of Common Lisp macros to develop PostScript programs!

OpenLaszlo is a high level XML/JavaScript based programming language, which compiles into Flash byte code that runs in the Flash player, and works exactly the same across all platform. The inner loops and hot-spots of Laszlo are hand written in "flasm" (Flash Assembler), as hand optimized alternatives to the compiled JavaScript code. (Laszlo is a JavaScript compiler that currently outputs SWF code, but will support other virtual machines in the future.) Flasm looks a lot like NeWS PostScript code, with all the stack comments. Laszlo is open source, so you can grab a copy of the LPS sources and look at "LaszloView.as" to see what I mean.

-Don

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Technically, it's The X-Windows Disaster.

If you think "AJAX" is a new idea, then read the description of how NeWS downloads interactive code to avoid client/server round trips, compared to the horrible inefficiency of X-Windows.

-Don

http://www.xahlee.org/UnixResource_dir/_fastfood_d ir/unixdead_j_dvorak.html

The following is from the August '86 issue of the DEC Professional, pilfered from http://catalog.com/hopkins/unix-haters/etc/unix-is -dead.html
Unix is Dead! Wanna Fight??
John C. Dvorak
Summer is over and a plague of UNIX programmers is upon us. College kids, wet behind the ears; greenhorns, rubes. They pour out of various campuses talking about ROFF and ED and pipes and paths, and they look for work. They're impressed with themselves. After all, they've learned the language of a secret society. If they're from Berkeley, they've learned the secret language of a secret society.

They all program in C, and wherever they go they change the prompts on whatever computer they get their hands on so it resembles a UNIX machine. They creative ones go into whatever operating system they have to use and find a symbol or token table; then they change the commands to look like UNIX. The *more* creative ones customize the commands further so they are even more cryptic and weird than UNIX. Whether these people ever do any real work is a mystery.

"Yes, weeell, to list my files I merely type P; MJOI."

"P; MJOI?? What they heck does that mean?"

"It just so happens that if I put my coffee cup on the keyboard and rock it a certain way, that's what it will type; so, I do that to list my files!"

While it's good to see these kids doing something other than wasting quarters on endless games of Pole Position, I'm not so sure UNIX dabbling is much better for society.

I feel this way, not so much because UNIX is an old-fashioned OS that has a special place reserved in hell, but because its time has passed. UNIX is dead, but no one bothered to claim the body. It lives like a zombie on college computers and serves as a gateway to all sorts of weird networks.

UNIX haunts marketing men, too. I remember when Fortune Systems was getting started. That's about the time that a bumper crop of college-bred UNIX drones was dumped like mulch into the marketplace. They all were singing the praises of UNIX to the low end of the market.

So, I went to this strategy demonstration given by one of the vice presidents of Fortune Systems. These guys surely were ahead of their time, and it was a perfect example of having too much bad information. The Fortune 16:32 (or was it 32:16? In either case it looked like a biblical reference...) said unto us: "Come to me for thine microprocessor and spend, spend, spend!" it was the first camel of microcomputers. Like a horse designed by committee (aka camel), the Fortune was preceded by too much market research. A lot of this was skewed by the hordes of UNIX maniacs running through the valley waving the UNIX flag.

First of all, I was shown a slide that clearly showed the Motorola 68000 as the world's greatest microprocessor.

The 68000 beat everything. Personally, I can't remember what it was pitted against -- probably the 8080, the 6502 and a 4004. Whatever, this was the chip to use.

Then the company did some market research and, because writers, pundits, researchers, secretaries, publishers, and programmers all said that UNIX was the next hot operating system, they chose it for their own little machine.

The UNIX community yelled, "Yea!" But, they continued to use free university-provided time, and none of the UNIX hackers bought the little UNIX boxes. Well, that was okay, it was intended to be a business machine, anyway.

Ooops! Gee, it seems that the businessmen couldn't cope with UNIX and "$ ls /bin/pr -p -t" or any other such nonsense. So they had to build a performance-sapping shell around the system, code name: SLOW. So much for the UNIX world takeover. I figured that would be the last I heard of it.

No

Really? I understood the whole episode to be a superbly-constructed allegory on the ultimately self-destructive nature of violent antisocial behaviour, with a side-moral on the dangers of hubris and the essential importance of external affirmation as an error-preventative strategy... or something... :-\

(Yeah, ok, I used to date a Lit Crit major. And you've obviously never handed in a paper on Postmodernism, either - your post was a feasible, intelligible and practically credible treatise. This is Postmodernism - You don't get points for being right, you know, just for being clever ).

The idea isn't new: This is also the case with Emacs of course, which is why it's so powerful. But Emacs lacks a way to plug in new code written in other languages.

Unfortunately Kinetix (now Discrete) didn't understand jack-shit about scripting languages until John Wainwright explained it to them by implementing MaxScript and showing them what it could do. Before that, Kinetix thought it would be a good idea to script 3D Studio Max with Java, which was just foolish. Java may be a lot of things, but a scripting language it's not.

When I wrote the character animation system for The Sims, I originally developed a 3D Studio Max exporter plug-in in C++, using the same code that ran in the game to create and export content. But I ran up against the limitations of the inflexable exporter plug-in interface, and it was impossible to make a decent user interface to configuring the many parameters, drive it from a database, use it to batch export more than once file at once, or check the integrity of the content and provide feedback to the artist.

Then a new version of Max with MaxScript came along, that had an SDK for developing plug-in MaxScript language extensions. So I rewrote the exporter as a MaxScript extension, then it was easy to script a user interface dialog so the artists could configure and control the exporter, integrate it with the database and source code control system, perform batch exports, and provide detailed feedback, warnings and error messages. Maxis used it to develop content for the original game, 7 expansion packs, and The Sims Online.

As a programming language, MaxScript is a lot like Kaleida's ScriptX, which is a lot like Dylan, Scheme, CLOS and Lisp. It's no co-incidence, because John Wainwright was the cheif architect of ScriptX as well as MaxScript. We worked together at Kaleida, where I programmed in ScriptX. Since I liked ScriptX, I also liked MaxScript. It has its quirks and limitations, but the important thing about it was not the syntax, but that it was easy to plug code into it, and extend the language.

In the ideal world, Kinetix should have had something like that from day one, but they didn't, and 3D Studio Max's quality and ability still suffers in comparison to Maya, which was done right from day one.

In the real world of developing content for virtual worlds, it's absolutely necessary to integrate new and pre-existing code and libraries into tools like 3D Studio Max, and script them with a high level open-ended language. It's not enought to have a close-ended toy language like JavaScript. It requires a real extensible language like Python or MaxScript, so programmers can plug their own binary code and modules into the scripting language itself, instead of being bound to inflexible single purpose plug-in interfaces.

-Don

5.2. Tab Windows The objects on the deck are displayed in windows with labeled tabs sticking out of them, showing the data type of the object. You can move an object around by grabbing its tab with the mouse and dragging it. You can perform direct stack manipulation, pushing it onto stack by dragging its tab onto the spike, and changing its place on the stack by dragging it up and down the spike. It implements a mutant form of "Snap-dragging", that constrains non-vertical movement when an object is snapped onto the stack, but allows you to pop it off by pulling it far enough away or lifting it off the top. [Bier, Snap-dragging] The menu that pops up over the tab lets you do things to the whole window, like changing view characteristics, moving the tab around, repainting or recomputing the layout, and printing the view.

-Don

5.2. Tab Windows The objects on the deck are displayed in windows with labeled tabs sticking out of them, showing the data type of the object. You can move an object around by grabbing its tab with the mouse and dragging it. You can perform direct stack manipulation, pushing it onto stack by dragging its tab onto the spike, and changing its place on the stack by dragging it up and down the spike. It implements a mutant form of "Snap-dragging", that constrains non-vertical movement when an object is snapped onto the stack, but allows you to pop it off by pulling it far enough away or lifting it off the top. [Bier, Snap-dragging] The menu that pops up over the tab lets you do things to the whole window, like changing view characteristics, moving the tab around, repainting or recomputing the layout, and printing the view.

-Don

Here are some pictures of dockable tab windows in a visual PostScript debugger for NeWS called "PSIBER (for PostScript Interactive Bug Eradication Routines)", that I wrote at the University of Maryland Human Computer Interaction Lab in 1989. And also Tab Windows with Pie Menus for The NeWS Toolkit that I wrote at Sun in 1990.

What's ironic is that Adobe wrote PostScript, so I corresponded with Adobe employees about PSIBER when I was writing it, even sending them early copies of the source code. Understandably they were very interested in a visual PostScript debugger. So Adobe certainly knew about prior art of docking tabbed windows since 1989.

-Don

Here are some pictures of dockable tab windows in a visual PostScript debugger for NeWS called "PSIBER (for PostScript Interactive Bug Eradication Routines)", that I wrote at the University of Maryland Human Computer Interaction Lab in 1989. And also Tab Windows with Pie Menus for The NeWS Toolkit that I wrote at Sun in 1990.

What's ironic is that Adobe wrote PostScript, so I corresponded with Adobe employees about PSIBER when I was writing it, even sending them early copies of the source code. Understandably they were very interested in a visual PostScript debugger. So Adobe certainly knew about prior art of docking tabbed windows since 1989.

-Don

Here are some pictures of dockable tab windows in a visual PostScript debugger for NeWS called "PSIBER (for PostScript Interactive Bug Eradication Routines)", that I wrote at the University of Maryland Human Computer Interaction Lab in 1989. And also Tab Windows with Pie Menus for The NeWS Toolkit that I wrote at Sun in 1990.

What's ironic is that Adobe wrote PostScript, so I corresponded with Adobe employees about PSIBER when I was writing it, even sending them early copies of the source code. Understandably they were very interested in a visual PostScript debugger. So Adobe certainly knew about prior art of docking tabbed windows since 1989.

-Don

Here are some pictures of dockable tab windows in a visual PostScript debugger for NeWS called "PSIBER (for PostScript Interactive Bug Eradication Routines)", that I wrote at the University of Maryland Human Computer Interaction Lab in 1989. And also Tab Windows with Pie Menus for The NeWS Toolkit that I wrote at Sun in 1990.

What's ironic is that Adobe wrote PostScript, so I corresponded with Adobe employees about PSIBER when I was writing it, even sending them early copies of the source code. Understandably they were very interested in a visual PostScript debugger. So Adobe certainly knew about prior art of docking tabbed windows since 1989.

-Don

Now I realize why X-Windows is still so popular with crappy GUI application developers.

They can blame all their horrible user interface problems on the X-Windows-Manager, so they don't have to bother fixing them.

-Don

From the X-Windows chapter of the Unix-Haters Handbook:

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

Now I realize why X-Windows is still so popular with crappy GUI application developers.

They can blame all their horrible user interface problems on the X-Windows-Manager, so they don't have to bother fixing them.

-Don

From the X-Windows chapter of the Unix-Haters Handbook:

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

Now I realize why X-Windows is still so popular with crappy GUI application developers.

They can blame all their horrible user interface problems on the X-Windows-Manager, so they don't have to bother fixing them.

-Don

From the X-Windows chapter of the Unix-Haters Handbook:

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

Now I realize why X-Windows is still so popular with crappy GUI application developers.

They can blame all their horrible user interface problems on the X-Windows-Manager, so they don't have to bother fixing them.

-Don

From the X-Windows chapter of the Unix-Haters Handbook:

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

From where I stand, I have no idea what people are talking about when they complain about X. They never say anything specific.

You want specific? Here you go!

-jcr

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

James Gosling certainly knew about Arthur van Hoff before 1993, at least since 1989 when Arthur released his amazing "GoodNeWS".

While I was working at Sun from 1990-1991, we flew Arthur out from Scotland to California and negotiated with him about integrating GoodNeWS aka HyperNeWS aka COOL aka HyperLook) into Sun's X11/NeWS window system. We spent quite a bit of time redesigning a new version of HyperNeWS for The NeWS Toolkit, I ported HyperNeWS to TNT, and Arthur delivered a prototype of the new system called "COOL" (Customizable Open Look).

Arthur was well known and respected in the NeWS community for his incredible work with HyperNeWS, NeWS, PostScript, a C to PostScript compiler called PdB, an SGML parser, and other amaing stuff. We lobbied Sun quite hard to convince them to hire Arthur, but they strung him along for a long time then finally refused, because they wanted to kill NeWS instead of doing something great with it.

But I wanted to work with Arthur anyway, so I left Sun and went out to the Turing Institute in Glasgow Scotland, to work with Arthur. We developed HyperNeWS into a product called "HyperLook", which we released in 1992. HyperLook included a wonderful PostScript graphics editor that you could use to create user interface components and customize the look and feel of the desktop with PostScript code and graphics.

I also ported SimCity to SunOS and used HyperLook to build the SimCity user interface and client/server interface, which we released at the same time.

As Peter Delany wrote on 10-29-1991:

Ok, I'll try to liven things up a little. Perhaps Don Hopkins or the XNeWS developers

Pat Naughton and James Gosling, could follow up with a few tid bits. Or a line from Tim Niblett and Author v

[...]

Everyone notices the obvious built-in political bias, whatever that is. But everyone sees it from a different perspective, so nobody agrees what its real political agenda actually is. I don't think it's all that important, since SimCity's political agenda pales in comparison to the political agenda in the eye of the beholder.

Some muckety-muck architecture magazine was interviewing Will Wright about SimCity, and they asked him a question something like "which ontological urban paridigm most influenced your design of the simulator, the Exo-Hamiltonian Pattern Language Movement, or the Intra-Urban Deconstructionist Sub-Culture Hypothesis?" He replied, "I just kind of optimized for game play."

Then there was the oil company who wanted "Sim Refinery", so you could use it to lay out oil tanker ports and petrolium storage and piping systems, because they thought that it would give their employees useful experience in toxic waste disaster management, in the same way SimCity gives kids useful experience in being the mayor of a city. They didn't realize that the real lessons of SimCity are much more subtle than teaching people how to be good mayors. But the oil company hoped they could use it to teach any other lessons on their agenda just by plugging in a new set of graphics, a few rules, and a bunch of disasters.

And there was the X-Terminal vendor who wanted to adapt the simulator in SimCity into a game called "Sim MIS", that they would distribute for free to Managers of Information Systems, whose job it is to decide what hardware to buy! The idea was that the poor overworked MIS would have fun playing this game in which they could build networks with PCs, X-Terminals, and servers (instead of roads with residential, commercial, and industrial buildings), that had disasters like "viruses" infecting the network of PC's, and "upgrades" forcing you to reinstall Windows on every PC, and business charts that would graphically highlight the high maintanence cost of PCs versus X-Terminals. Their idea was to use a fun game to subtly influence people into buying their product, by making them lose if they didn't. Unlike the oil company, they certainly realized the potential to exploit the indirect ways in which a game like SimCity can influence the user's mind, but they had no grip on the concept of subtlety or game design.

[...]

-Don

Whatever happened to NeWS?

A GUI-based pizza ordering tool? It's old news, I hate to tell ya.

An engineer at Sun did this almost 10 years ago at Sun Microsystems. It was called pizzatool. Here's a screenshot. Notice how it even renders the proposed pizza for you before ordering. Also notice that it works by sending a fax; this was back before there were any companies accepting pizza orders over the web! As proof of its age, notice that the GUI is actually is actually built with the OpenLook toolkit.

Also note that it doesn't order any Domino's Pizza or any crap like that. It orders Tony and Alba's . Now that's some good pizza.

That was a great uproar and a good package. Dan Farmer sure took some flak for that one. He lost a good security gig with SGI as I recall.

But one of the coolest parts of the kit was the postscript file that featured an Intel-like logo that read "Satan Inside".

I had great fun printing those on self-adhesive transparency material and widely distributing..

A quick search turned up one of many sources for the postscript:

Satan Inside

-Don

The Nongraphical GUI

X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?

Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn't get all of those ugly fonts. It's a trade-off.

[...]

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cu

-Don

The Nongraphical GUI

X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?

Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn't get all of those ugly fonts. It's a trade-off.

[...]

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cu

Mike said "Richard, I heard a rumor about your house burning down".

Richard chimed back, "Yes, but where you work, I expect you'd have heard about it in advance!"

Here's a picture of Devon climbing onto the roof of said house, before it burnt down. (No, Devon wasn't breaking in to set the fire on behald of UniPress Software -- Devon lived there too.)

-Don

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be