Slashdot Mirror

Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).

You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]

Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).

-Don

Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).

You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]

Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).

-Don

Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).

You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]

Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).

-Don

Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).

You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]

Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).

-Don

OpenLaszlo kinda is Flash:
"OpenLaszlo is designed to use open standards, and built with open source tools and technologies. It's a high level architecture designed to target multiple rendering environments, and the first one it currently supports is Flash.

OpenLaszlo's platform independent architecture gives it the ability to target other runtime environments like DHTML, Java, XUL, Avalon, SVG, open source Flash players "

If OpenLaszlo apps run in Flash VMs, and do what Flash does, then it effectively is Flash, by competing directly with actual Flash code.

The Future of Content
What I learned about content from the Sims.
...and why it's driven me to procedural methods.
...And what I now plan to do with them.
Will Wright
Game Developers Conference
3/11/2005

Joel Jones and her family Will Wright and Cassidy Wright just published this beautiful new book, which I highly recommend:

Mirror Lake is the natural environment where Joell Jones, Will Wright and Cassidy Wright retreat for vacation to draw inspiration. Proceeds from this new book go to the Turtle Nest Protection Program.

Through the paintings and photographs of authors Joell Jones, Will Wright, and Cassidy Wright, this gift book looks at the nature and environment of Fripp Island, off the coast of North Carolina near Beaufort. The images and musings span more than two decades of visits to a coastal vacation spot that mirrors the process of leisure development in natural settings all over the world. In it we see and read about many aspects of nature, including the loggerhead turtles that once hatched freely on Fripp's beaches.

About the Authors

Joell Jones is an exhibiting artist with her studio in Oakland, California. She received her BA from Louisiana State University at Baton Rouge, and her MA from JFK University in Orinda, California. She studied painting with Michelle Cassou. Joell is married to co-author Will Wright and mother of co-author Cassidy Wright.

Will Wright is co-founder of Maxis Software Company in Emeryville, California, and designer of the computer games SimCity, The Sims, and Spore. Wright was given a Lifetime Achievement Award at the Game Developers Choice Awards in 2001. He has been informally photographing at Fripp Island since 1999.

Cassidy Wright has been involved in art exhibits, and in the inventor sport of Robot Wars, since she was eight years old. In 2004 she entered the California College of the Arts in Oakland, California, to investigate her interests in a variety of media. She has been photographing at Fripp Island since 2000.

Of course I'm familiar with Maya's marking menus and Gordon Kurtenbach's work, which are based on the ideas from (and refer to) the paper, "An Empirical Comparison of Pie vs. Linear Menus", that we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published in 1988.

The first publication that described the basic idea of pie menus was "PIXIE: A New Approach to Graphical Man-Machine Communications"; by Wiseman, N. E., Lemke, H. U., and Hiles, J. O.; Proceedings of 1969 CAD Conference Southhampton, IEEE Conference Publication 51, p. 463. The basic idea was also described in "Principles of Interactive Computer Graphics, 2nd. edition"; by Newman, W. M. and Sproull, R. F.; McGraw-Hill, 1979, 1973. Both of those came out a long time before Maya/Alias/PowerAnimator.

In the mean time, I've developed pie menus for many different platforms, including X10 (uwm+forth), X11 (piewm, TCL/Tk), NeWS 1.0, 1.1 (Lite Toolkit), OpenWindows (TNT/Open Look), Multi Player SimCity (X11/TCL/Tk), The Sims (C++/DirectX), ActiveX/OLE (C++), Internet Explorer DHTML Behaviors (JavaScript/XML), Palm (C++/XML), Pocket PC (C++/Lua), SVG (JavaScript), and OpenLaszlo (JavaScript/XML). In my copious spare time I'm also working on developing pie menus for World of Warcraft (Lua/XML)!

-Don

Of course I've heard of Steve Mann's work, and his Gnu/Linux Wristwatch Video Phone, which used pie menus (but didn't talk as far as I know). He built his prototype pie menu watch in 1998, about 10 years after we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published a paper about pie menus at ACM CHI'88. But in 1988 (and 1998), not many people had hardware they could carry around that was suitible for implementing talking pie menus.

Speech synthesis requires a lot of memory to store a good voice, and speech enabled applications require a lot of task-specific scripting control (so they don't start talking and talking at length about something the user is no longer interested in). I'm using the Lua scripting language on the Pocket PC, to develop flexible speech enabled touch screen pie menu based interfaces, which will run on commonly available Pocket PC phones. (I've done a lot of Palm programming in the past, but that's a dead platform.)

Here's a video that Dave Winer took of me demonstrating an example application: a remote control for "Rock and Roll".

-Don

The real question is: Will you still be around when the web's finally won? If you had any perspective, you would realize what an abomination PHP is, and know that we're a long way from realizing the full potential from the web. There's no reason for you to be repeating the mistakes of the past by using PHP, which there are so many better solutions available. How long have you been around, to accuse me of being a newbie?

I've been developing hypermedia browsers and distributed user interfaces ("AJAX") since 1988. I wrote my first hypermedia browser in PostScript, Forth and C, for the NeWS window system, in 1988, and it was called "HyperTIES":

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
http://www.donhopkins.com/drupal/node/102

I also wrote a hypermedia authoring tool with UniPress Emacs in MockLisp (this article has many images and links to documentation and source code written in C, Forth, PostScript, MockLisp and HyperTIES markup language):

HyperTIES Hypermedia Browser and Emacs Authoring Tool for NeWS
http://www.donhopkins.com/drupal/node/101

And I wrote my first web server in ScriptX and C, in 1995:

ScriptX and the World Wide Web: "Link Globally, Interact Locally"
http://www.donhopkins.com/drupal/node/118

Here is the web server module documentation:
http://www.google.com/search?q=cache:XgEgHkBwCBMJ: www.art.net/~hopkins/Don/lang/scriptx/web.html&hl= en&gl=us&ct=clnk&cd=1

The HyperTIES markup language supported macros, conditionals, loops, variables, even user defined interactive widgets ("applets" scripted in PostScript), and we designed to be easy to understand, with a simple uniform syntax, low syntactic surface area, few exceptions to the rules, consistent naming conventions. In short, everything that PHP lacks. And that was in 1988.

There is no excuse for PHP's horrible design. If you're not aware of its flaws, then you're not qualified to use it. So stop making excuses for it.

-Don

The real question is: Will you still be around when the web's finally won? If you had any perspective, you would realize what an abomination PHP is, and know that we're a long way from realizing the full potential from the web. There's no reason for you to be repeating the mistakes of the past by using PHP, which there are so many better solutions available. How long have you been around, to accuse me of being a newbie?

I've been developing hypermedia browsers and distributed user interfaces ("AJAX") since 1988. I wrote my first hypermedia browser in PostScript, Forth and C, for the NeWS window system, in 1988, and it was called "HyperTIES":

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
http://www.donhopkins.com/drupal/node/102

I also wrote a hypermedia authoring tool with UniPress Emacs in MockLisp (this article has many images and links to documentation and source code written in C, Forth, PostScript, MockLisp and HyperTIES markup language):

HyperTIES Hypermedia Browser and Emacs Authoring Tool for NeWS
http://www.donhopkins.com/drupal/node/101

And I wrote my first web server in ScriptX and C, in 1995:

ScriptX and the World Wide Web: "Link Globally, Interact Locally"
http://www.donhopkins.com/drupal/node/118

Here is the web server module documentation:
http://www.google.com/search?q=cache:XgEgHkBwCBMJ: www.art.net/~hopkins/Don/lang/scriptx/web.html&hl= en&gl=us&ct=clnk&cd=1

The HyperTIES markup language supported macros, conditionals, loops, variables, even user defined interactive widgets ("applets" scripted in PostScript), and we designed to be easy to understand, with a simple uniform syntax, low syntactic surface area, few exceptions to the rules, consistent naming conventions. In short, everything that PHP lacks. And that was in 1988.

There is no excuse for PHP's horrible design. If you're not aware of its flaws, then you're not qualified to use it. So stop making excuses for it.

-Don

The real question is: Will you still be around when the web's finally won? If you had any perspective, you would realize what an abomination PHP is, and know that we're a long way from realizing the full potential from the web. There's no reason for you to be repeating the mistakes of the past by using PHP, which there are so many better solutions available. How long have you been around, to accuse me of being a newbie?

I've been developing hypermedia browsers and distributed user interfaces ("AJAX") since 1988. I wrote my first hypermedia browser in PostScript, Forth and C, for the NeWS window system, in 1988, and it was called "HyperTIES":

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
http://www.donhopkins.com/drupal/node/102

I also wrote a hypermedia authoring tool with UniPress Emacs in MockLisp (this article has many images and links to documentation and source code written in C, Forth, PostScript, MockLisp and HyperTIES markup language):

HyperTIES Hypermedia Browser and Emacs Authoring Tool for NeWS
http://www.donhopkins.com/drupal/node/101

And I wrote my first web server in ScriptX and C, in 1995:

ScriptX and the World Wide Web: "Link Globally, Interact Locally"
http://www.donhopkins.com/drupal/node/118

Here is the web server module documentation:
http://www.google.com/search?q=cache:XgEgHkBwCBMJ: www.art.net/~hopkins/Don/lang/scriptx/web.html&hl= en&gl=us&ct=clnk&cd=1

The HyperTIES markup language supported macros, conditionals, loops, variables, even user defined interactive widgets ("applets" scripted in PostScript), and we designed to be easy to understand, with a simple uniform syntax, low syntactic surface area, few exceptions to the rules, consistent naming conventions. In short, everything that PHP lacks. And that was in 1988.

There is no excuse for PHP's horrible design. If you're not aware of its flaws, then you're not qualified to use it. So stop making excuses for it.

-Don

Since X-Windows is so pixel oriented, a natural scripting language would be a two-dimensional cellular automata like John von Neuman's 29 State Cellular Automata, which can run "Universal Constructor" programs that reproduce theselves or any other program. Since it's Turing Complete, you could script an emulator for any other language!

-Don

I wrote The Sims 1 Crowd Sitter to simulate the effects of Bush's (lack of) response to Hurricaine Katrina.

-Don

Kid, you are completely missing the point. Go back and read the fucking article. OpenLaszlo is a high level XML/JavaScript based language that COMPILES into SWF, and now also COMPILES into DHTML/JavaScript. It's INDEPENDENT of Flash, because it targets other runtimes, including browsers WITHOUT the Flash plug-in.

Your misunderstanding is like complaining that C++ locks you into 68000 machine language, because the first version of CGG initially targeted 68k. C++ is a (moderately) high level language that can be compiled to many different platforms. GCC in no way dependent on the 68000 processor, and it doesn't directly expose any 68000 specific features, so code you write in C++ can compile to any processor that the compiler supports. Do you see the analogy?

To take the analogy a bit further, Cygnus made their money by supporting GCC and porting it to other platforms like the Sony Playstation, in many cases paid for by the developers of the platforms themselves. Laszlo Systems uses a similar open source model, developing OpenLaszlo applications like Laszlo Mail for big corporate customers like Earthlink, and enhancing OpenLaszlo to support popular platforms like DHTML and the latest version of Flash.

On the other hand, FLEX is like a proprietary version of GCC that only compiles code written in a non-portable platform-specific language that only runs on one vendor's processor, and the code you write is by design NOT portable to any other platform, and you're NOT allowed to look at or modify the compiler source code, NOR modify it to support other platforms. And that's a lot less useful than an open source platform independent language like OpenLaszlo. FLEX is a textbook example of vendor lock-in, because it's purposefully design so it doesn't support any other platform than Flash.

Adobe has a long track record of using vendor lock-in to tie customers into their products, and then quietly dropping their support for products without warning developers that they're about to have the rug pulled out from under them. Case in point: SVG. The SVG generated by Adobe's tools only works in Adobe's SVG viewer, and do you really think SVG has a future at Adobe, now that they've bought Macromedia and moved onto Flash? Adobe was the main company propping up SVG, just because they were fighting against Macromedia Flash, and that's over now. The fat lady has sung, and SVG is dead.

-Don

... that is, help you get around being bored by the now-slashdotted, currently unreadable website pushing the story mentioned in the parent post.

In fine off-topic form, with absolutely no relevance to the site mentioned above (which none of us can read anyway):
http://www.wheresmyho.com/

It's a website to find hookers. Like, as a web service or something. Looks like a joke site to me, albeit a different kind of joke (and imho, a funnier one) than the server that's powering the story at http://www.donhopkins.com/drupal/node/124

Owch! I restarted apache and mysql, made a static text mirror of the drupal page, and RewriteRuled it into place at the original url: http://www.donhopkins.com/drupal/124 Now maybe you can fetch the article, I hope.

Sorry about the embarassing Dru Paux.

-Don

Note: Open Source SimFaux OpenLaszlo Code Now Available via Subversion, so you can add your own characters and content!

SimFaux is an Interactive Faux News Simulation Game, a parody of Fox News, now online and FauxCasting from the Huffington Post Contagious Festival!

SimFaux is like a cross between The Sims and Mystery Science Theater, that lets you sit back and channel surf, or take control and create your own Faux News TV programs! It's pronounced "Sim Foe", of course!

Free live interactive SimFaux Simualtion Game (requires Flash, preferably version 8): http://simfaux.cf.huffingtonpost.com/

Screencast and demo video: http://www.simfaux.com/

I just posted the latest version of SimFaux, which currently has:

8 Simulated Characters with graphics and sound bites:
1) Arianna Huffington
2) Dick Cheney
3) George W Bush
4) Frank Zappa
5) Ann Coulter
6) Al Franken
7) Triumph the Insult Comic Dog
8) Bill O'Reilly

Channel Surfing (8 different channels with many different programs)

Create your own TV program:
Select any character, video feed to other information to display in each frame.
Invite any character onto your show.
Tell characters to talk, shut up, go away.

WebCam Support:
Put yourself on-screen and interview and argue with the characters!

Streaming Video Clips with keyword triggers.

Video backgrounds and overlays.

Keyword driven AI simulation:
All content is tagged and triggered with keywords, used by simulation to decide which video clips and sound bites to play.

Keyword display:
See active keywords, hide and focus on keywords to drive simulation

Meaningless graphs and chart-junk.

Interactive surveys with loaded questions and ballot box stuffing.

Teleprompter talking points with reference links so you can really decide for yourself.

Faux Chat simulated Internet chat room:
All character sound bites go into chat.
Amusing chat logs with keyword triggers that effect simulation.
Type text and keywords into chat to reply to characters and effect simulation.

SimFaux is written in OpenLaszlo, which is an Open Source XML/JavaScript based programming language for rich zero-install AJAX web applications:

http://www.openlaszlo.org/

SimFaux is a constantly evolving open-ended simulation game, which makes it easy to drop in new content (movies, characters, sound bites, text talking points, chat transcripts) all tagged up with keywords, so they play off of each other!

I want to enable other people to start FauxCasting their own stuff! So I will soon publish the source code for SimFaux as Open Source, to serve as an OpenLaszlo programming example, and so other people can modify it an add their own content, videos, characters, sound bites, games, etc! Please check the site http://www.simfaux.com/ for more information.

I am continuously adding more late breaking content and up-to-the-minute news, so please check back again later, and tell your friends about SimFaux!

-Don Hopkins (dhopkins@DonHopkins.com)

From Stanislaw Lem's "Non-Serviam" (1971):

(Personetics): A "world" for personoid "inhabitants" can be prepared in a couple of hours... A specific personoid activity serves as a triggering mechanism, setting in motion a production process that will gradually augment and define itself; in other words, the world surrounding these beings takes on an unequivocalness only in accordance with their own behavior... From four to seven personoids are optimal, at least for the development of speech and typical exploratory activity, and also for 'culturization'... It is possible to 'accommodate' up to one thousand personoids... Many different philosophies (ontologies and epistemologies) have arisen among them... I can enlarge their world or reduce it, speed up its time or slow it down, alter the mode and means of their perception; I can liquidate them, divide them, multiply them, transform the very ontological foundation of their existence...

On the lighter side of personetics... I'm developing an open source "Personetics" system called "SimFaux", which I've applied to parody Fox News, so it currently includes simulations of George W Bush, Dick Cheney, Bill O'Reilly, Ann Coulter, Frank Zappa, Arianna Huffington, Al Franken and Triumph the Insult Comic Dog.

I've published the SimFaux source code and content as Free Open Source, so you can make your own characters, experiment with the existing ones, transform the very ontological foundation of their existence, see how the keyword based simulation works, extend it with your own rules and content, learn how to build interactive interfaces and simulations with streaming video in OpenLaszlo, etc.

-Don

That's quite true: Haskell's notion of pattern matching is much more powerful and extensible than mere regular expressions.

Jim Clark's Haskell implementation of the derivative algorithm for validating Relax NG is a wonderful example of how powerful, elegant and concise Haskell is. Relax NG is all about tree structured regular expressions over "hedges" (mixed trees of XML elements and text). It's based on the same automata theory as regular expressions, extended to describe "hedges" (XML documents).

An Algorithm for RELAX NG Validation By James Clark, January 07, 2001. Author's note to XML-DEV: 'I have written a paper describing one possible algorithm for implementing RELAX NG validation. This is the algorithm used by Jing, which I believe has also been adopted by MSV... If you try to use this to implement RELAX NG and something isn't clear, let me know and I'll try to improve the description.' From the introduction: "This document describes an algorithm for validating an XML document against a RELAX NG schema. This algorithm is based on the idea of what's called a derivative (sometimes called a residual). It is not the only possible algorithm for RELAX NG validation. This document does not describe any algorithms for transforming a RELAX NG schema into simplified form, nor for determining whether a RELAX NG schema is correct. We use Haskell to describe the algorithm. Do not worry if you don't know Haskell; we use only a tiny subset which should be easily understandable." Jing is a validator for RELAX NG implemented in Java;

Another interesting Haskell library for XML is HaXml:

Consider Haskell in lieu of DOM, SAX, or XSLT for processing XML data. The library HaXml creates representations of XML documents as native recursive data structures in the functional language Haskell. HaXml brings with it a set of powerful higher order functions for operating on these "datafied" XML documents. Many of the HaXml techniques are far more elegant, compact, and powerful than the ones found in familiar techniques like DOM, SAX, or XSLT. Code samples demonstrate the techniques.

Here's some more stuff about Relax NG, comparing the Haskell implementation to the Java implementation (jing): Maximizing Composability and Relax NG Trivia:

Here's some interesting stuff about the design and development of Relax NG:

James Clark wrote about maximizing composability:

First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.

Clark describes the derivative algorithm's lazy approach to automaton construction:

I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the

Actually, ActiveX does run just fine on the Mac, and has for a long time. I used it in 1996 to develop a plug-in system for a visual programming language called Bounce, and Mac Common Lisp). Metrowerks actually modified their C++ compiler to support it (adding a _comobject magic class that you can inherit from to get the vtable pointers formatted in the right place so multiple inheritance and QueryInterface worked together properly). Microsoft used it to port IE to the Mac, and paid Metrowerks to make the modifications to support it.

ActiveX/COM is actually quite a cool and useful technology, which is why Firefox uses XPCOM on all platforms, a clone of ActiveX/COM. Mozilla's XPCOM isn't the only clone of COM: before Mozilla developed XPCOM, Macromedia developed their own ActiveX clone called MOA on all platforms. mTropolis mFactory also had its own COM clone called MOM. There are actually lots of COM clones, many of which are incompatible with the real thing and require their own special tool chains to develop plug-ins (which is ironic since the goal of COM was cross language binary compatibility).

And yes, MacIE is a horrible wretched piece of crap, and open sourcing it would be a pointless waste of time. The JavaScript interpreter is uselessly sub-standard, and the DHTML implementation is missing many important features.

Microsoft hired a bunch of excellent Mac programmers to develop it, and they wrote much of their own code base from scratch (using the Metrowerks Powerplant gui toolkit, totally different than the new Aqua [old NeXT Step] libraries), but Microsoft pulled the rug out from under them before they could fix any of the bugs, and wouldn't let them support it, instead diverting them to other projects like WebTV. So it's languished for many years, and even if it were open sourced, it would be an enormous amount of work to bring it up to being compatible with modern web browsers.

-Don

Things that happen when you say 'X Windows':

I was digging through some old papers, and ran across a 15 year old "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2, from June 1988. Here's an article that illustrates how far the usage of the term "X Windows" has evolved over the past 15 years. (Too bad The Window System Improperly Known as X Windows itself hasn't evolved.)

Someone on slashdot asks, "Why is it still called X-Windows?". Predictably, the first reply says: "It isn't. It's called 'The X Window System.' Or simply 'X'. 'X Windows' is a misnomer."

He didn't ask why it is "X-Windows". He asked why it's called "X-Windows". You're wrong that it isn't called "X-Windows". It is! It's just that it isn't "X-Windows". Being something is independent of being called something.

The answer to the question 'Why is it still called X-Windows?' is: It's still called X-Windows in order to annoy the X-Windows Fanatics, who take it upon themselves to correct you every time you call it X-Windows. That's why it's called X-Windows.

The following definitive guide to the consequences of saying "X Windows" is from the June 1988 "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2:

Things That Happen When You Say 'X Windows'

THE OFFICAL NAMES
The official names of the software described herein are:
X
X Window System
X Version 11
X Window System, Version 11
X11

Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).

The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!

You are forced to explain toolkit programming to X neophytes.

Bob Schiefler says, "You should know better than that!"

The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.

Ditto for the controller board for the disk on your new Sun.

Your hair falls out.

xmh refuses to come up in a useful size, no matter what you fiddle.

You inexplicitly lose both of your complete Ultrix Doc sets.

R2 won't build.

Bob Schiefler says "Type 'man X'".

Your nifty new X screen saver just won't go away.

The window you're working in loses input focus. Permanently.

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

FYI, I'm not latching onto or regurgitating someone else's complaints as if they're my own -- I wrote that chapter in the Unix Haters handbook, based on years of experience with X. I attended the original X conference at MIT, and I've been using X since X10, ported SimCity to X11, developed a multi player user interface for SimCity that supported multiple servers connected to the same X11 client, and sold multiplayer SimCity as a commercial product in 1992. So I think I have the right to complain about the shortcomings of X, without being accused of regurgitating someone else's opinion.

Here's some nifty X10 window manager code I wrote in Forth in 1986:

X.f - X10 window system interface for Forth.
Xlib.f - X10 XLib interface for Forth.
xutil.f - X10 utilities for Forth.
uwm.f - X10 uwm window manager interface for Forth.
load-fuwm.f - X10 uwm library loader for Forth window manager.
fuwm-main.f - X10 Forth window manager main driver.
menulist.f - pie menus and linear menus for Forth window manager. hacks.f - X10 Forth window manager hacks.

I extended Gancarz's original X10 "uwm" window manager in C to support pie menus, then I broke it up into a library so I could link it into Mitch Bradley's Sun Forth (Forthmacs) and script it in Forth. We used it to perform an experiment comparing pie menus and linear menus. (Pie menus won hand down!)

The last file (hacks.f) is especially fun, because it lets you pick up windows and fling them around the screen, so any number of windows will bounce around on the screen with inertia and gravity and friction, each with their own Forth task. It ran quite fast on a 4 meg Sun 3/50, with enough room for Emacs to bounce around too.

Programming a window manager with a stack based language foreshadowed the work I later did with the NeWS window system and user interface toolkit, which is an extensible window system written by James Gosling, scripted in PostScript.

Ever heard of AJAX? NeWS did cool stuff that X still can't touch 20 years later, like dynamically downloading code to the server to define efficient application specific protocols and implememt locally interactive custom user interfaces. AJAX is not a new idea, and it wasn't even invented by Microsoft: NeWS was totally "AJAXian" 20 years ago, but with PostScript code instead of JavaScript, PostScript graphics instead of HTML, and PostScript data instead of XML -- much more consistent and easier to program than AJAX's potpourri of incompatible standards!

Believe it or not: with NeWS, you could actually draw circles and diagonal lines in PostScript without making a remote procedure call to download an image (like Google Maps has to do, in order to support Firefox).

-Don

Certainly, Lisp is a better language than Java, in theory. But take a look at the actual Emacs Lisp you're comparing to Java. The Lisp in Emacs is a yucky old loosely nailed together plywood treehouse Erzatz Lisp, with "buffer scoping" thrown in, which makes it totally unlike any standard Lisp implementation, plus it has no native code extension API (plugins or DLL modules). No other Lisp but Emacs Erzatz Lisp stores variables bindings in buffers, such that when you switch buffers, your variable bindings change!

Gnu Emacs wasn't the first Emacs to use a mutant Erzatz Lisp. At least Gnu Emacs Erzatz Lisp was an improvement over Gosling Emacs "MockLisp" (UniPress Emacs). MockLisp resembles Lisp only in the worst possible way (same annoyingly pesky parenthetical syntax, but none of the solid well designed semantics).

MockLisp actually used an ill-conceived form of lazy evaluation, which is lethal when foolishly combined with dynamic scoping (no closures). When you called a MockLisp function, the parameters were't evaluated until the called function decided to fetch the argument with the (arg name prompt) function (which also would prompt the user for the argument if it was missing).

The horrible problem with MockLisp was that the (arg) fetching function evaluated the CALLER's parameter expression in the CALLEE's dynamic scope! Bzzzt! Argument expressions could be passed deep down from function to function, so you had no way of knowing what context any of your arguments would be evaluated in. So thanks to dynamic scoping, you actually had to name ALL of your local variables uniquely across the entire MockLisp program (which causes problems when integrating packages written by different people). The convention was to use a unique prefix for all arguments of each function, cross your fingers, and for God's sake don't get recursive.

MockLisp was so un-lisp-like that it didn't even have basic data types like dictionaries. This MockLisp code (a hypermedia browser authoring tool for HyperTIES) implemented a master index to look up article titles and synonyms, and it had to represent a dictionary as a buffer, and abuse buffer local keyboard abbreviation tables (which were fast because they were implemetned in C) to look up names.

It's astounding how disasterously designed MockLisp was, yet Gnu Emacs Erzatz Lisp still copied some of its ill-conceived ideas like buffer scoping. Emacs implemented with a real Lisp programming language would simply represent buffers as regular data types, and provide sane variable scoping (i.e. an object oriented programming system like CLOS) so that there was no need for "buffer scoping" built into the language. There's nothing so special about buffers that they deserve to be built into the programming language's scoping rules.

MockLisp is to Lisp as JavaScript is to Java. They're both badly designed programming languages that ripped off the names of better designed programming languages, to fool people into believing they didn't suck.

-Don

AJAX Special Hazard Precautions

Anyone who tries to tell you that AJAX is a " new approach to web applications" is just rebranding old technology and hyping buzzwords, not engineering software in the real world. Because of browser and DHTML incompatibilities and limitiations, AJAX is like cocaine: it seems glamorous until you actually start using it, then the unintended consequences totally fuck you up.

Special Hazard Precautions for AJAX:

INGESTION: NAUSEA, VOMITING, AND DIARRHEA. EYES: EYE IRRITANT UPON DIRECT CONTACT. SKIN: MAY CAUSE SKIN IRRITATION UPON PROLONGED CONTACT. INHALATION: NONE UNDER NORMAL USE. PROLONGED INHALATION BY UNORTHODOX USE (NON-WETTED) OR ABUSE (SNIFFING) COULD PRODUCE LUNG DISEASE (SILICOSIS). N/K

Emergency/First Aid Proc: INGEST: IF EATEN/DRUNK--YOU MAY THROW UP. DRINK SIPS OF WATER/MILK. IF VOMIT CONTINUES, CALL POISON CTR/DR. EYES: IRRIT. FLUSH W/WATER 15 MIN. IF IRRIT PERSISTS, CALL POISON CTR/DR. SKIN: IRRIT. REMOVE WET CLOTHES. FLUSH W/WARM WATER 15 MIN. IF IRRIT PERSISTS, CALL DR/POISON CTR. INHAL: IF INHALED, MAY COUGH. TAKE SLOW DEEP BREATHS OF FRESH AIR, SIP WATER. IF COUGH PERSISTS, CALL DR/POISON CTR.

Here's the entire Ajax information sheet, with more warnings and hazard precautions.

-Don

How ironic that they released the LispM sources under a BSD-like license instead of GPL.

Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.

Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.

Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Computers. (There were only five of us dancing, but we had a good time.)

[...] The Lab Betrayed

There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.

For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.

Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.

The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.

Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.

This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.

I strongly suspect that the destruct

How ironic that they released the LispM sources under a BSD-like license instead of GPL.

Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.

Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.

Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Computers. (There were only five of us dancing, but we had a good time.)

[...] The Lab Betrayed

There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.

For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.

Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.

The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.

Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.

This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.

I strongly suspect that the destruct

HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.

HyperTIES supported browsing interactive hypermedia including formatted text and scalable PostScript graphics, including interactive software components like applets, pie menus, embedded graphical menus, text and graphics editors, etc, written in the NeWS object oriented dialect of PostScript.

The HyperTIES hypermedia browser was also integrated with an authoring tool, based on the Unipress Emacs text editor, which could remotely control the browser (so Emacs could navigate the browser and display the content you're editing), and the browser could remotely control Emacs (so you could create hypermedia interfaces with text links and graphical menus that drove Emacs).

Illustration: HyperTIES Browser (right) and UniPress Emacs Multi Window Text Editor Authoring Tool (left), tab windows and pie menus, running under the NeWS Window System.

Illustration: HyperTIES Browser NeWS Client/Server Software Architecture.

Paper: Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser

By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

[...] Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.

[...] Implications of Graphics in Hypertext
Hyperties incorporates graphics while preserving the embedded menu approach used for textonly documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author

HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.

HyperTIES supported browsing interactive hypermedia including formatted text and scalable PostScript graphics, including interactive software components like applets, pie menus, embedded graphical menus, text and graphics editors, etc, written in the NeWS object oriented dialect of PostScript.

The HyperTIES hypermedia browser was also integrated with an authoring tool, based on the Unipress Emacs text editor, which could remotely control the browser (so Emacs could navigate the browser and display the content you're editing), and the browser could remotely control Emacs (so you could create hypermedia interfaces with text links and graphical menus that drove Emacs).

Illustration: HyperTIES Browser (right) and UniPress Emacs Multi Window Text Editor Authoring Tool (left), tab windows and pie menus, running under the NeWS Window System.

Illustration: HyperTIES Browser NeWS Client/Server Software Architecture.

Paper: Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser

By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

[...] Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.

[...] Implications of Graphics in Hypertext
Hyperties incorporates graphics while preserving the embedded menu approach used for textonly documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author

HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.

HyperTIES supported browsing interactive hypermedia including formatted text and scalable PostScript graphics, including interactive software components like applets, pie menus, embedded graphical menus, text and graphics editors, etc, written in the NeWS object oriented dialect of PostScript.

The HyperTIES hypermedia browser was also integrated with an authoring tool, based on the Unipress Emacs text editor, which could remotely control the browser (so Emacs could navigate the browser and display the content you're editing), and the browser could remotely control Emacs (so you could create hypermedia interfaces with text links and graphical menus that drove Emacs).

Illustration: HyperTIES Browser (right) and UniPress Emacs Multi Window Text Editor Authoring Tool (left), tab windows and pie menus, running under the NeWS Window System.

Illustration: HyperTIES Browser NeWS Client/Server Software Architecture.

Paper: Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser

By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

[...] Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.

[...] Implications of Graphics in Hypertext
Hyperties incorporates graphics while preserving the embedded menu approach used for textonly documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author

The NeWS window system was "Ajaxian" back in the 90's, but it used PostScript instead of JavaScript, PostScript instead of HTML, and PostScript instead of XML. In other words, it was PostScript based, with a much more consistent architecture than AJAX, but it used the same essential techniques like downloadable code, local interaction, asynchronous network communication, etc.

Under the direction of Ben Shneiderman, we developed the HyperTIES hypermedia browser in NeWS, which downloaded PostScript programs and data into the NeWS window system, that implemented the HyperTIES user interface and rendered the interactive hypermedia content.

As well as supporting fully scalable PostScript graphics and text, you could also embed "applets" written in PostScript on the HyperTIES page, like pie menus, text and graphics editors, and other kinds of locally interactive user interfaces that communicate asynchronously with the HyperTIES engine and Emacs based authoring tool.

HyperTIES is described in the paper "Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser, by Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

The NeWS window system was "Ajaxian" back in the 90's, but it used PostScript instead of JavaScript, PostScript instead of HTML, and PostScript instead of XML. In other words, it was PostScript based, with a much more consistent architecture than AJAX, but it used the same essential techniques like downloadable code, local interaction, asynchronous network communication, etc.

Under the direction of Ben Shneiderman, we developed the HyperTIES hypermedia browser in NeWS, which downloaded PostScript programs and data into the NeWS window system, that implemented the HyperTIES user interface and rendered the interactive hypermedia content.

As well as supporting fully scalable PostScript graphics and text, you could also embed "applets" written in PostScript on the HyperTIES page, like pie menus, text and graphics editors, and other kinds of locally interactive user interfaces that communicate asynchronously with the HyperTIES engine and Emacs based authoring tool.

HyperTIES is described in the paper "Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser, by Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

The NeWS window system was "Ajaxian" back in the 90's, but it used PostScript instead of JavaScript, PostScript instead of HTML, and PostScript instead of XML. In other words, it was PostScript based, with a much more consistent architecture than AJAX, but it used the same essential techniques like downloadable code, local interaction, asynchronous network communication, etc.

Under the direction of Ben Shneiderman, we developed the HyperTIES hypermedia browser in NeWS, which downloaded PostScript programs and data into the NeWS window system, that implemented the HyperTIES user interface and rendered the interactive hypermedia content.

As well as supporting fully scalable PostScript graphics and text, you could also embed "applets" written in PostScript on the HyperTIES page, like pie menus, text and graphics editors, and other kinds of locally interactive user interfaces that communicate asynchronously with the HyperTIES engine and Emacs based authoring tool.

HyperTIES is described in the paper "Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser, by Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.

Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:

• an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
• application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
• multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.

I'll start by comparing screen corners to pie menus:

To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."

But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.

Pie menus "slices" are better than "screen corners" or "menu bars" because:

Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.

Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.

Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.

Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!

Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.

Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.

Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.

Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)

Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.

Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc

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: