Slashdot Mirror

Once you know the direction of the pie menu item you want, you can quickly select it without even looking at the screen, by mousing ahead. It's like using a keyboard accelerator, but without moving your hand from the mouse to the keyboard and back. The accelerated action is exactly the same as the unaccelerated action, only faster.

But selecting from a linear menu is not rehearsal for using the keyboard accelerator, because typing on the keyboard is a completely different action than selecting from the menu with the mouse, so you have twice as many actions to learn. To use the keyboard accelerator, you have to learn a completely new command that has nothing to do with the menu, and interrupts the flow of mouse actions.

It takes at least a second to move your hand between the mouse and keyboard and readjust, so it's important to provide keyboard equivalents for commands you'll be using while typing. I'm not suggesting removing keyboard accelerators when adding pie menus. Pie menus have their own built-in accelerators (mousing ahead without looking), that is extremely easy to use if you're already pointing and clicking with the mouse (which is the case with a game like The Sims, that doesn't use the keyboard very much).

Of course there's no reason why you couldn't assign traditional keyboard accelerators to individual pie menu items. The ActiveX pie menus have full support for keyboard navigation, so you can select and navigate and use all their features from the keyboard as well as the mouse.

Four item and eight item pie menus map very nicely to the arrow keys and numeric keypad. The ActiveX pie menus can automatically limit the maximum number of items per pie menu to eight, and let you page up and down through arbitrarily long menus in groups of eight items at a time, with the mouse or keyboard.

The newer JavaScript Pie Menus for Internet Explorer don't support keyboard navigation yet. Here's a description of many of the features of the older ActiveX pie menus, which are fancier but don't integrate with the web page as nicely or support dynamic HTML rendering and XML configuration like the newer Javascript pie menus.

-Don

An example of research in user interfaces is Denim which aims to marry the advantages of old fashioned pen+paper design with the convenience of having the computer handle the details. The idea is to allow the designer to freely sketch with a tablet but also add hyperlinks between sketches as the design progresses. There's a sample of the generated mockup, but really the videos on the page linked above are really neat. They show a person using a tablet to do a sample design. The software also incorporates some other modern interface ideas such as the zoomable UI and the pie menu.

It is very interesting to see the fairly old technology of Pie menus implemented yet again. Somehow, one would think that there should be a lot more implementations,
given that pie menus show up again and again...

Ubiquitous Computing

Ubiquitous computing names the third wave in computing, just now beginning. First were mainframes, each shared by lots of people. Now we are in the personal computing era, person and machine staring uneasily at each other across the desktop. Next comes ubiquitous computing, or the age of calm technology, when technology recedes into the background of our lives. Alan Kay of Apple calls this "Third Paradigm" computing.

Mark Weiser is the father of ubiquitous computing; his web page contains links to many papers on the topic.

Two recent papers express elements of the ubiquitous computing philosophy: "Open House" (also in a MS Word version) , and "Designing Calm Technology".

What Ubiquitous Computing Isn't

Ubiquitous computing is roughly the opposite of virtual reality. Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. Virtual reality is primarily a horse power problem; ubiquitous computing is a very difficult integration of human factors, computer science, engineering, and social sciences.

Early work in Ubiquitous Computing The initial incarnation of ubiquitous computing was in the form of "tabs", "pads", and "boards" built at Xerox PARC, 1988-1994. Several papers describe this work, and there are web pages for the Tabs and for the Boards (which are a commercial product now):

Ubicomp helped kick off the recent boom in mobile computing research, although it is not the same thing as mobile computing, nor a superset nor a subset.

Ubiquitous Computing has roots in many aspects of computing. In its current form, it was first articulated by Mark Weiser in 1988 at the Computer Science Lab at Xerox PARC. He describes it like this:

Early Work in Ubiquitous Computing

Ubiquitous Computing #1

Inspired by the social scientists, philosophers, and anthropologists at PARC, we have been trying to take a radical look at what computing and networking ought to be like. We believe that people live through their practices and tacit knowledge so that the most powerful things are those that are effectively invisible in use. This is a challenge that affects all of computer science. Our preliminary approach: Activate the world. Provide hundreds of wireless computing devices per person per office, of all scales (from 1" displays to wall sized). This has required new work in operating systems, user interfaces, networks, wireless, displays, and many other areas. We call our work "ubiquitous computing". This is different from PDA's, dynabooks, or information at your fingertips. It is invisible, everywhere computing that does not live on a personal device of any sort, but is in the woodwork everywhere.

Ubiquitous Computing #2

For thirty years most interface design, and most computer design, has been headed down the path of the "dramatic" machine. Its highest ideal is to make a computer so exciting, so wonderful, so interesting, that we never want to be without it. A less-traveled path I call the "invisible"; its highest ideal is to make a computer so imbedded, so fitting, so natural, that we use it without even thinking about it. (I have also called this notion "Ubiquitous Computing", and have placed its origins in post-modernism.) I believe that in the next twenty years the second path will come to dominate. But this will not be easy; very little of our current systems infrastructure will survive. We have been building versions of the infrastructure-to-come at PARC for the past four years, in the form of inch-, foot-, and yard-sized computers we call Tabs, Pads, and Boards. Our prototypes have sometimes succeeded, but more often failed to be invisible. From what we have learned, we are now explorting some new directions for ubicomp, including the famous "dangling string" display.

========

"Dedicated to the memory of Mark Weiser and Alan Turing"

-Don

What he didn't mention is that Microsoft never invented those things -- they're simply exploiting the "Ubiquitous Computing" research developed by other people at Xerox PARC, MIT Media Lab, and many others places.

Our product ConnectedTV, which we demonstrated at CES, is also inspired by the same Ubiquitous Computing research, as well as using other proven user interface techniques like pie menus.

Besides the personalized TV guide and universal remote control, it has many useful home control applications, as well. For an idea of where it's heading, please read some the literature.

We owe a lot to pioneering researchers like the late Mark Weiser (director of Xerox PARC Computer Science Lab), and visionary writers like the late Philip K Dick. May they forever continue to guide and inspire us from half-life.

-Don

"I am Ubik. Before the universe was, I am. I made the suns. I made the worlds. I created the lives and the places they inhabit; I move them here, I put them there. They go as I say, then do as I tell them. I am the word and my name is never spoken, the name which no one knows. I am called Ubik, but that is not my name. I am. I shall always be."

-Glenn Runciter

That would be Quorum's Mac compatibility library. I evaluated the Quorum library in 1991, for use in porting the Mac version of SimCity to Unix. But I decided it would be much better to do a completely native port of SimCity to Unix instead of using a Mac emulation library.

The application and Quorum library are compiled on Unix, and provided API level compatibility (not binary), layered on top of a lame-assed X11 toolkit (Motif). So the application would have to be ported the the native C compiler and recompiled on Unix, unlike the much more successful approach that Transgaming has taken with Wine and The Sims on DirectX.

The main appeal of using a Mac emulation library like Quorum was that it would not require changing (much of) the original SimCity source code (modulo compiler incompatibilities, which are numerous).

But there was really no point to that, because the code was already forked, and being able to compile the same code on multiple platforms was not an issue. The whole point of porting SimCity to Unix was to take advantage of Unix features that Quorum's emulation library could not support, like pie menus and the multi player ability.

Doing a native port required much work rewriting the user interface from scratch, but that was what I wanted to do. So I used HyperLook on NeWS (which is similar to NeXTStep and Cocoa in that it uses the PostScript imaging model), and then implemented Multi Player SimCity using TCL/Tk on X11.

Adobe used Quorum to port Photoshop 2.5 to the Sun Solaris and SGI Irix platforms. I still have my original CD and manual for Sun Photoshop 2.5, which was only ever useful as a coaster. It was totally unusable, because it was so slow, with many glitches in the user interface, and it would crash at the slightest misplaced mouse click.

Because of the way that the single tasking Mac-centric interruptable screen redisplay algorithm clashed with the asynchronous X-Windows protocol and bloated Motif toolkit, you had to take your hands off the keyboard and mouse and sit on them while you waited for Photoshop to finish drawing everything, before it was safe to use.

Of course there weren't any commercial plug-ins available on the Sun or SGI platforms, because porting Photoshop plug-ins to Suns or SGIs was extremely tricky, thanks to the Mac compatibility layer. (Plug-ins didn't have a dynamic linking mechanism to call back into X11 and Motif, to implement their control panel guis).

The Quorum library's approach is quite different from the more successful binary level compatibility approach that Transgaming is taking to run The Sims on Linux.

I've been harshly criticized by fanatic Loki supporters for justifying Transgaming's emulation approach, instead of native ports. But Loki had their chance to perform a native port of The Sims, and blew it. Don't blame Transgaming for figuring out a way to do it successfully after Loki failed to.

I'm not religiously beholden to one technique or another. I'm interested in getting the best results, so I've used many different approaches myself. An emulated port is far better than no port at all. And there are many different approaches to porting and emulation, some better than others.

The particular application as well as the particular platforms involved play extremely important roles in deciding how to best perform a port. There are also many economic issues. There is no one best approach that's right all the time. And porting software is always going to be a lot of work. If you're not willing to put enough effort into it, the results will always be horrible no matter which approach you take.

-Don

One alternative is Ken Perlin's QuikWriting, which has been discussed on slashdot and covered by Wired.

"Quikwriting is significantly faster and less stressful to use than Graffiti, and lets you write very quickly without ever picking your stylus up off the surface, although it has the disadvantage that you need to learn a special alphabet. For further info, you can preview a Technote in either PDF or PostScript, which was published at the ACM UIST'98 conference."

Another alternative that builds on Perlin's QuikWriting work, is Francois Guimbretiere's and Terry Winograd's FlowMenus, published at UIST'00.

"We present a new kind of marking menu that was developed for use with a pen device on display surfaces such as large, high resolution, wall-mounted displays. It integrates capabilities of previously separate mechanisms such as marking menus and Quikwriting, and facilitates the entry of multiple commands. While using this menu, the pen never has to leave the active surface so that consecutive menu selections, data entry (text and parameters) and direct manipulation tasks can be integrated fluidly."

I'm currently designing and programming a user interface on the Palm for a remote control application. So I've implemented "Finger Pies", which are simply pie menus that you can use with your finger!

To paraphrase Ben Shneiderman: Finger Pies work well for implementing direct manipulation user interfaces on handheld personal touch screen devices, in which the application provides meaningful, engaging, tightly coupled feedback on the screen, in response to your gesture. By integrating immediate gratification over time, the user enjoys the satisfaction of direct engagement in an immersive experience, and achieves the cognitive resonance of continuous gratification. [My apologies to Ben for the tongue in cheek impression.]

Finger Pies are not meant to replace character input systems like Graffiti, but they are extremely useful and reliable for many applications of handheld input devices, because they're easy enough to use with your finger instead of a pen.

Finger pies are good for reliably selecting between two, four or eight options at a time (which can be nested as pop up submenus), and they're much more robust and resistant to noise than gesture recognition.

One problem with gesture recognition in general, is that it doesn't allow for "reselection" or in-flight refinement and error correction. That is, once you've made a mistake in a gesture, there's no way to change or cancel it, so you will often get characters that you don't mean, and you have to stop what you're doing and erase the mistake.

Pie menus allow you to cancel or change the selection at any time before you commit to the selection, so you can easily browse the menus. So pie menus are most appropriate when there aren't too many items, the items don't change dynamically over time, and when you need to minimize the error rate and selection time.

Most gesture recognition systems are not "self revealing" like pie menus, which can pop up a "map" showing the directions. So pie menus are much easier to learn than gesture recognition, and more appropriate for novice users. Best of all, they naturally train users to "mouse ahead" and select without looking, so they have a smooth, gentle learning curve.

Another advantage of pie menus is that they're not patented or restricted, and there are several freely available open source implementations.

-Don

Penny Lane: "This song was written about the roundabout in liverpool where John and Paul grew up. Half of the song is fact, half is fiction, but most of it is nostalgia. John was starting to write about personal places, and Paul really took this one and ran. "I wrote that the barber had photographs of every head he'd had the pleasure of knowing. Actually, he just had photos of different hair styles. But all the people do stop and say hello." say Paul. Also, "finger pie" is actually an old obscenity in Liverpool. The girls would never thnk of saying the word. It was used in the song as a fun joke for the lads back home. Months after, waitresses in Liverpool had to put up with lads asking for "fish and finger pie." There is also a phallic reference to the "fireman who keeps his fire engine clean." Penny Lane has become a Beatles landmark, and like Blue Jay Way, has it's problems with stolen signs, which are now nicely bolted down. Penny Lane was recorded on December 29, 1966 and released as a single with Strawberry Fields.The song also has a promotional video." -http://members.aol.com/Sumacca/songs.html

If some day GNOME, GCC, GNU Emacs, and all of GNU are obsolete and forgotten, but computer users generally are free to share and change the software they use, these programs will have done their job well. If, on the other hand, GNOME and the rest of the GNU system are widely used, but mainly in combination with proprietary software, they will have succeeded only part-way, and a big task will remain ahead of us.

Does this paragraph indicate that RMS would support KDE, if KDE meets his definition of free software? Note: I'm not trying to start a flame war about GNOME vs. KDE. I'm just asking if RMS, in his answer to this question, would support stopping the GNOME project in favor of a more popular, more established, more whatever GUI environment for the GNU system. Maybe KDE is that system. If so, would RMS, if part of the GNOME board, work to further the goals of KDE if he felt that KDE was a better GUI for the GNU system?

It's interesting that this discussion came up at exactly the same time that I'm browsing around looking at Pie Menus. And at one time they say that they are tightly integrated with IE and Active X, but in the next sentance they claim that they are free and unrestricted. My immediate reaction was that they can hardly be free if they're tightly integrated with something that is non-free. In other words, the use of free software obligates me to use non-free software, which obligates me to support a company I find reprehensible. Is that sort of thing extending or restricting my freedom?

And then someone goes and posts this, and now I find myself taking the exact opposite stance. While I'd like to agree with RMS, I can't. Just because GNOME is a GNU project does not mean that GNOME must subjugate it's responsibilities to its own success in order to maintain "higher responsibilities" to the success of GNU and free software.

That's kinda like the draft isn't it? When our country calls us to die for the furtherance of its goals. It's great if you, as a citizen, volunteer for that responsibility, but it's a whole other ball of wax when you're forcibly required to do it.

What to think about this? What to think? Hmmm.....

The pie menus in The Sims use a combination of desaturation, darkening, and alpha blending to feather the edges of the menu.

Why transparency and the other effects? I didn't want the pie menus to obscure too much of the scene behind them. You can see through the pie menu as the animation continues on in real time behind it. The head of the currently selected person is drawn in the center of the pie menu, and follows the cursor by looking at the currently selected item.

I found it necessary to somehow separate the head from the rest of the scene, otherwise it looked like a giant head was floating in a room of the house! Drawing a solid opaque menu background would obscure too much of the scene. But even a partially transparent menu background still did not visually separate the head from the background scene enough. It looked muddy and cluttered, instead of crisp and bright.

So instead of simply alpha blending, I actually made it desaturate the background (removes the color so it's gray scale), and darken it (like casting a colorless shadow).

I wanted the colorful head to look sharp and bright up against the dark gray background. So the effect looks at the Z buffer to clip out the head in the menu center, so it remains bright and colorful against the dark gray background. That gives it visual "pop" that separates the head from the background. The edges of the effect are feathered, so there's no sharp line dividing the inside and the outside of the menu (useless visual clutter).

The gray shadow just gradually tapers off with distance, suggesting that the pie menu active area extends to the edge of the screen, not confined to the borders of a circle. The labels are drawn with high contrast drop shadows around the pie menu, so they stand out and easy to read, partially overlapping the shadow so they're look like they're part of the menu.

There's special code to perform that particular combination of pixel filters in real time, to every frame just after the 3D rendering phase.

The pixelated censorship effect works the same way as the pie menu shadow, like a Photoshop filter run after the 3D rendering phase. There's a special suit type that's tagged as a "censorship" suit. It consists of bounding boxes attached to the varius bones of the skeleton that you can select to censor. So if you just want to censor the head, you attach the head censor suit to the head bone. The 3D character renderer transforms the 8 vertices but doesn't draw anything, and stashes the screen bounding box away for the pixelation filter to draw later. That's how it can censor just the crotch of naked men, but also the chests of naked girls gone wild.

-Don

Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?

Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."? What previous work do you mean?

Are you refering to my work writing The X-Windows Disaster chapter for The Unix-Haters Handbook? I wrote that AFTER porting SimCity to X11 with TCL/Tk, compared with my previous experience porting SimCity to NeWS with HyperLook.

Or has my work with pie menus for ActiveX, Internet Explorer and other crass commercial products tainted me as Politically Incorrect?

I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.

-Don

Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?

Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."? What previous work do you mean?

Are you refering to my work writing The X-Windows Disaster chapter for The Unix-Haters Handbook? I wrote that AFTER porting SimCity to X11 with TCL/Tk, compared with my previous experience porting SimCity to NeWS with HyperLook.

Or has my work with pie menus for ActiveX, Internet Explorer and other crass commercial products tainted me as Politically Incorrect?

I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.

-Don

Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?

Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."? What previous work do you mean?

Are you refering to my work writing The X-Windows Disaster chapter for The Unix-Haters Handbook? I wrote that AFTER porting SimCity to X11 with TCL/Tk, compared with my previous experience porting SimCity to NeWS with HyperLook.

Or has my work with pie menus for ActiveX, Internet Explorer and other crass commercial products tainted me as Politically Incorrect?

I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.

-Don

Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?

Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."? What previous work do you mean?

Are you refering to my work writing The X-Windows Disaster chapter for The Unix-Haters Handbook? I wrote that AFTER porting SimCity to X11 with TCL/Tk, compared with my previous experience porting SimCity to NeWS with HyperLook.

Or has my work with pie menus for ActiveX, Internet Explorer and other crass commercial products tainted me as Politically Incorrect?

I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.

-Don

This seems a bit like asking what it would take to replace the current way of driving a car (steering wheel, gas and pedal brakes, etc.) with something better. But the interface between humans and automobiles is pretty much a solved problem, and nobody seems to spend much time speculating on what a paradigm change in automobile control would be like.

Oh yeah? Two words: cruise control. It completely redefined the "car interface". How about two more: intermittent wipers. True, the inventor got shafted by Detroit and had to fight tooth and nail for years to get his due, but he too changed the "car interface" dramatically.

There's a curious assumption which I've seen repeatedly-- namely, that a paradigm shift in human/computer interaction would be a good thing. Why, exactly?

Simple: because the quantum increase in computer access that was engendered by the WIMP interface isn't by any stretch of the imagination the endpoint of interface evolution. Want an example? Don Hopkins has been pushing his concept of Pie Menus for about 15 years now, and has implemented them everywhere he can find an amenable display system (starting with (*shudder*) X10 and including MS-Windows!). If you think you know how user interfaces should work and you haven't read any of Don's exhortations on the human-factors improvements inherent in non-linear menus, you need to get with the program.

I've tried it, and it worked quite well for my purposes. It's good for implementing plug-in reusable easily configured components, that are much simpler to plug in, more reusable and easier to configure than anything you can do in straight-up JavaScript.

There's a technology called "Dynamic HTML Behavior Components", that let you package up a bunch of JavaScript code in an XML file, describing its interface: properties, methods and events. And attach that object to any DHTML element, as a behavior that can respond to events, access dhtml tag attributes, web page content, expose methods and events, etc.

That DHTML Behavior interface can be implemented in any scripting language like JavaScript, VBScript, Python, Ruby, whatever, through ActiveScripting.

That's why ActiveScripting is so important and useful. It lets any language call and use components written in any other language, so you can both implement and utilise components from any language that plugs into ActiveScripting.

Plug-in behaviors are easy to attach to any dhtml element, like so:

<div style="behavior:url(piemenu.htc)"/>

You can easily pass arguments to configure the behavior through dhtml attributes, like so:

<div id="Pie" style="behavior:url(piemenu.htc)" piemenu="MyMenu" fixedradius="40" onselect="MyHandler()"/>

The component exposes properties and methods you can access from scripts on the web page, that cna be written in JavaScript, VBScript, Python or whatever. Like so:

Pie.fixedRadius = 40
Pie.DoPie(Pie.GetRootPieMenu())

And the component can access embeded "XML Data Islands" on the web page, or dynamically created by JavaScript code, or downloaded from a server, or dynamically generated from a database, or the results of evaluating and XSLT style sheet, etc. XML data islands are a great way to embed XML data on a web page, that the scripts as well as the components can access. XML is a perfect way to represent the tree structure of pie menus, as well as embedded XHTML that specifies the presentation of the pie menu items and middle. So you can configure the pie menu component on the web page by embeding an XML data island inside the element to which you attach the pie menu behavior. Like so:

<div style="behavior:url(piemenu.htc)"
id="Pie"
fixedradius="40"
onselect="HandleSelect(event)">
Click here to pop up a pie menu.
<xml>
<piemenu name="Hello World">
&lthtml&gt
<B>Hello</B>, <EM>World</EM>!
&lt/html&gt
<item name="Hello"/>
<item name="World"/>
</piemenu>
</xml>
</div>

My point is, that this technology saves a lot of time and effort, and makes it quite easy to implement powerful reusable modular components, that are in turn extremely easy for other people to use.

If anything in Internet Explorer is worth for Mozilla to emulate, it's the ActiveScripting and plug-in DHTML Behavior Component technology.

Stop bashing it out of ignorance, and learn about it. Then figure out how to support it in Mozilla.

Don't try to come up with something better, when you're already so far behind, and 95% of the world is already using Internet Explorer. That's why Mozilla is so far behind. They've been pissing away time trying to implement all these untested half baked ideas, instead of putting time into supporting the standards that already exists, like Microsoft has already done.

Don't believe me? Let me recap some of the promises Netscape made, but never kept, when they should have been working on standard support for DHTML, XML, XSLT, and ActiveX.

The Netscape plug-in API is trivial and useless compared to ActiveX or even the older OLE stuff. It didn't need to be as complicated as OLE, but it sure needed to be a whole lot more powerful and not as half-baked as it was.

Rewriting the browser in Java. They put a whole lot of time and effort of good people into that project, and it finally went nowhere. Netscape exployees couldn't stand working with Sun employees because they were arrogant and bickered all the time, so they couldn't get along well enough to produce anything. The project got canned.

Supporting OpenDoc. Netscape was OpenDoc's last hope. It held the promise of a real component system. More than that, OpenDoc's "killer app" was CyberDog, which was a totally beautiful component oriented web browser. (Well, a lot more than that, because of OpenDoc, but that's how they were selling it.) Of course the implications of integrating OpenDoc and Netscape were that they had to flush everything they'd done so far down the toilet and start over, possibly with CyberDog, or else from scratch. But Netscape was too arrogant to throw out what the'd done so far and take any advice from Apple. Mozilla was a huge monolithic monster that couldn't be simply broken down into a bunch of independent components. No fucking way. One or the other had to go. So after publically promising to support OpenDoc with great fanfare, and hiring the CyberDog team away from the already poor shrivled Apple, Netscape resolutely shot Old Yeller: they killed CyberDog, thus driving the last nail in the coffin of OpenDoc, and summarily fucking both Apple and IBM.

Sun observed OpenDoc's demise and the resulting fallout with the bearded delight of Osoma bin Laden watching CNN, because they wanted to promote their "100% pure" fundamentalist religion of JavaBeans (which at the time only existed as a widely announced name, and wasn't event designed yet) as the one alternative component framework to go up against ActiveX. But OpenDoc was in the way, so they danced on its grave when it died.

Then there was the time that Netscape hired a bunch of former NeXT guys, who had learned Java and decided to implement a NeXTStep-like toolkit in it. It worked really well, and looked really good, so Netscape hired those guys right up, named it "IFC" for "Internet Foundation Classes" so as to position it against MFC "Microsoft Foundation Classes", and announced that IFC was going to be the official "100% Pure Java" cross platform write once debug everywhere bla bla bla widget component toolkit for Netscape.

But the idea of another Java toolkit that wasn't vapourware spooked Sun, who was still vaporising their plans for JavaBeans and didn't want IFC taking away any of their media attention and mind share.

Sun was afraid of IFC because it had such a great name (nothing about the architecture mattered, except that it was not JavaBeans). IFC was what you got when you took the widely successful Microsoft Foundation Classes, removed the Microsoft, and replaced it with Internet instead. Yes, that kind of thinking really floats the boats of marketing people.

Sun saw IFC as a threat, as long as it was not under their control, so they called in an old favor they did Netscape, when they let them use the holy name "Java" to brand their scripting language that really didn't have anything to do with Java.

So Sun called in the "JavaScript" name favor, and Netscape turned IFC over to Sun in order to be "migrated" and "readjusted" to JavaBeans. Which really means they just disposed of the body, but stored the name away safely for later use.

Anyway, after all that, you can see why I have absolutely no faith in what the religiously anti-Microsoft zealouts come up with. Because their thinking is so clouded by their warped little models of the world, that no matter how good their technology is, they will destroy it for petty, stupid reasons.

Disclaimer: This is all my own warped and interpreted view of the world from my own perspective, as an ex-Sun-employee with an axe to grind, and other undocumented perspectives that I won't go into now, to protect my informers. Take it as fiction if you like.

The part about pie menus isn't fiction, though. You can download the free open source, documentation and demos at:

http://www.piemenu.com

The JavaScript pie menus for Internet Explorer 5.5 on Windows are at:

http://www.piemenu.com/JavaScriptPieMenus.html

And if you don't believe that pie menus are faster and more reliable than linear menus, you can prove it to yourself by playing the game "Fasteroids", and read all the source code if you don't trust me.

http://www.piemenu.com/fasteroids.html

As I said, it requires Internet Explorer 5.5 on Windows. But that was the whole point of this discussion.

-Don

I've tried it, and it worked quite well for my purposes. It's good for implementing plug-in reusable easily configured components, that are much simpler to plug in, more reusable and easier to configure than anything you can do in straight-up JavaScript.

There's a technology called "Dynamic HTML Behavior Components", that let you package up a bunch of JavaScript code in an XML file, describing its interface: properties, methods and events. And attach that object to any DHTML element, as a behavior that can respond to events, access dhtml tag attributes, web page content, expose methods and events, etc.

That DHTML Behavior interface can be implemented in any scripting language like JavaScript, VBScript, Python, Ruby, whatever, through ActiveScripting.

That's why ActiveScripting is so important and useful. It lets any language call and use components written in any other language, so you can both implement and utilise components from any language that plugs into ActiveScripting.

Plug-in behaviors are easy to attach to any dhtml element, like so:

<div style="behavior:url(piemenu.htc)"/>

You can easily pass arguments to configure the behavior through dhtml attributes, like so:

<div id="Pie" style="behavior:url(piemenu.htc)" piemenu="MyMenu" fixedradius="40" onselect="MyHandler()"/>

The component exposes properties and methods you can access from scripts on the web page, that cna be written in JavaScript, VBScript, Python or whatever. Like so:

Pie.fixedRadius = 40
Pie.DoPie(Pie.GetRootPieMenu())

And the component can access embeded "XML Data Islands" on the web page, or dynamically created by JavaScript code, or downloaded from a server, or dynamically generated from a database, or the results of evaluating and XSLT style sheet, etc. XML data islands are a great way to embed XML data on a web page, that the scripts as well as the components can access. XML is a perfect way to represent the tree structure of pie menus, as well as embedded XHTML that specifies the presentation of the pie menu items and middle. So you can configure the pie menu component on the web page by embeding an XML data island inside the element to which you attach the pie menu behavior. Like so:

<div style="behavior:url(piemenu.htc)"
id="Pie"
fixedradius="40"
onselect="HandleSelect(event)">
Click here to pop up a pie menu.
<xml>
<piemenu name="Hello World">
&lthtml&gt
<B>Hello</B>, <EM>World</EM>!
&lt/html&gt
<item name="Hello"/>
<item name="World"/>
</piemenu>
</xml>
</div>

My point is, that this technology saves a lot of time and effort, and makes it quite easy to implement powerful reusable modular components, that are in turn extremely easy for other people to use.

If anything in Internet Explorer is worth for Mozilla to emulate, it's the ActiveScripting and plug-in DHTML Behavior Component technology.

Stop bashing it out of ignorance, and learn about it. Then figure out how to support it in Mozilla.

Don't try to come up with something better, when you're already so far behind, and 95% of the world is already using Internet Explorer. That's why Mozilla is so far behind. They've been pissing away time trying to implement all these untested half baked ideas, instead of putting time into supporting the standards that already exists, like Microsoft has already done.

Don't believe me? Let me recap some of the promises Netscape made, but never kept, when they should have been working on standard support for DHTML, XML, XSLT, and ActiveX.

The Netscape plug-in API is trivial and useless compared to ActiveX or even the older OLE stuff. It didn't need to be as complicated as OLE, but it sure needed to be a whole lot more powerful and not as half-baked as it was.

Rewriting the browser in Java. They put a whole lot of time and effort of good people into that project, and it finally went nowhere. Netscape exployees couldn't stand working with Sun employees because they were arrogant and bickered all the time, so they couldn't get along well enough to produce anything. The project got canned.

Supporting OpenDoc. Netscape was OpenDoc's last hope. It held the promise of a real component system. More than that, OpenDoc's "killer app" was CyberDog, which was a totally beautiful component oriented web browser. (Well, a lot more than that, because of OpenDoc, but that's how they were selling it.) Of course the implications of integrating OpenDoc and Netscape were that they had to flush everything they'd done so far down the toilet and start over, possibly with CyberDog, or else from scratch. But Netscape was too arrogant to throw out what the'd done so far and take any advice from Apple. Mozilla was a huge monolithic monster that couldn't be simply broken down into a bunch of independent components. No fucking way. One or the other had to go. So after publically promising to support OpenDoc with great fanfare, and hiring the CyberDog team away from the already poor shrivled Apple, Netscape resolutely shot Old Yeller: they killed CyberDog, thus driving the last nail in the coffin of OpenDoc, and summarily fucking both Apple and IBM.

Sun observed OpenDoc's demise and the resulting fallout with the bearded delight of Osoma bin Laden watching CNN, because they wanted to promote their "100% pure" fundamentalist religion of JavaBeans (which at the time only existed as a widely announced name, and wasn't event designed yet) as the one alternative component framework to go up against ActiveX. But OpenDoc was in the way, so they danced on its grave when it died.

Then there was the time that Netscape hired a bunch of former NeXT guys, who had learned Java and decided to implement a NeXTStep-like toolkit in it. It worked really well, and looked really good, so Netscape hired those guys right up, named it "IFC" for "Internet Foundation Classes" so as to position it against MFC "Microsoft Foundation Classes", and announced that IFC was going to be the official "100% Pure Java" cross platform write once debug everywhere bla bla bla widget component toolkit for Netscape.

But the idea of another Java toolkit that wasn't vapourware spooked Sun, who was still vaporising their plans for JavaBeans and didn't want IFC taking away any of their media attention and mind share.

Sun was afraid of IFC because it had such a great name (nothing about the architecture mattered, except that it was not JavaBeans). IFC was what you got when you took the widely successful Microsoft Foundation Classes, removed the Microsoft, and replaced it with Internet instead. Yes, that kind of thinking really floats the boats of marketing people.

Sun saw IFC as a threat, as long as it was not under their control, so they called in an old favor they did Netscape, when they let them use the holy name "Java" to brand their scripting language that really didn't have anything to do with Java.

So Sun called in the "JavaScript" name favor, and Netscape turned IFC over to Sun in order to be "migrated" and "readjusted" to JavaBeans. Which really means they just disposed of the body, but stored the name away safely for later use.

Anyway, after all that, you can see why I have absolutely no faith in what the religiously anti-Microsoft zealouts come up with. Because their thinking is so clouded by their warped little models of the world, that no matter how good their technology is, they will destroy it for petty, stupid reasons.

Disclaimer: This is all my own warped and interpreted view of the world from my own perspective, as an ex-Sun-employee with an axe to grind, and other undocumented perspectives that I won't go into now, to protect my informers. Take it as fiction if you like.

The part about pie menus isn't fiction, though. You can download the free open source, documentation and demos at:

http://www.piemenu.com

The JavaScript pie menus for Internet Explorer 5.5 on Windows are at:

http://www.piemenu.com/JavaScriptPieMenus.html

And if you don't believe that pie menus are faster and more reliable than linear menus, you can prove it to yourself by playing the game "Fasteroids", and read all the source code if you don't trust me.

http://www.piemenu.com/fasteroids.html

As I said, it requires Internet Explorer 5.5 on Windows. But that was the whole point of this discussion.

-Don

I've tried it, and it worked quite well for my purposes. It's good for implementing plug-in reusable easily configured components, that are much simpler to plug in, more reusable and easier to configure than anything you can do in straight-up JavaScript.

There's a technology called "Dynamic HTML Behavior Components", that let you package up a bunch of JavaScript code in an XML file, describing its interface: properties, methods and events. And attach that object to any DHTML element, as a behavior that can respond to events, access dhtml tag attributes, web page content, expose methods and events, etc.

That DHTML Behavior interface can be implemented in any scripting language like JavaScript, VBScript, Python, Ruby, whatever, through ActiveScripting.

That's why ActiveScripting is so important and useful. It lets any language call and use components written in any other language, so you can both implement and utilise components from any language that plugs into ActiveScripting.

Plug-in behaviors are easy to attach to any dhtml element, like so:

<div style="behavior:url(piemenu.htc)"/>

You can easily pass arguments to configure the behavior through dhtml attributes, like so:

<div id="Pie" style="behavior:url(piemenu.htc)" piemenu="MyMenu" fixedradius="40" onselect="MyHandler()"/>

The component exposes properties and methods you can access from scripts on the web page, that cna be written in JavaScript, VBScript, Python or whatever. Like so:

Pie.fixedRadius = 40
Pie.DoPie(Pie.GetRootPieMenu())

And the component can access embeded "XML Data Islands" on the web page, or dynamically created by JavaScript code, or downloaded from a server, or dynamically generated from a database, or the results of evaluating and XSLT style sheet, etc. XML data islands are a great way to embed XML data on a web page, that the scripts as well as the components can access. XML is a perfect way to represent the tree structure of pie menus, as well as embedded XHTML that specifies the presentation of the pie menu items and middle. So you can configure the pie menu component on the web page by embeding an XML data island inside the element to which you attach the pie menu behavior. Like so:

<div style="behavior:url(piemenu.htc)"
id="Pie"
fixedradius="40"
onselect="HandleSelect(event)">
Click here to pop up a pie menu.
<xml>
<piemenu name="Hello World">
&lthtml&gt
<B>Hello</B>, <EM>World</EM>!
&lt/html&gt
<item name="Hello"/>
<item name="World"/>
</piemenu>
</xml>
</div>

My point is, that this technology saves a lot of time and effort, and makes it quite easy to implement powerful reusable modular components, that are in turn extremely easy for other people to use.

If anything in Internet Explorer is worth for Mozilla to emulate, it's the ActiveScripting and plug-in DHTML Behavior Component technology.

Stop bashing it out of ignorance, and learn about it. Then figure out how to support it in Mozilla.

Don't try to come up with something better, when you're already so far behind, and 95% of the world is already using Internet Explorer. That's why Mozilla is so far behind. They've been pissing away time trying to implement all these untested half baked ideas, instead of putting time into supporting the standards that already exists, like Microsoft has already done.

Don't believe me? Let me recap some of the promises Netscape made, but never kept, when they should have been working on standard support for DHTML, XML, XSLT, and ActiveX.

The Netscape plug-in API is trivial and useless compared to ActiveX or even the older OLE stuff. It didn't need to be as complicated as OLE, but it sure needed to be a whole lot more powerful and not as half-baked as it was.

Rewriting the browser in Java. They put a whole lot of time and effort of good people into that project, and it finally went nowhere. Netscape exployees couldn't stand working with Sun employees because they were arrogant and bickered all the time, so they couldn't get along well enough to produce anything. The project got canned.

Supporting OpenDoc. Netscape was OpenDoc's last hope. It held the promise of a real component system. More than that, OpenDoc's "killer app" was CyberDog, which was a totally beautiful component oriented web browser. (Well, a lot more than that, because of OpenDoc, but that's how they were selling it.) Of course the implications of integrating OpenDoc and Netscape were that they had to flush everything they'd done so far down the toilet and start over, possibly with CyberDog, or else from scratch. But Netscape was too arrogant to throw out what the'd done so far and take any advice from Apple. Mozilla was a huge monolithic monster that couldn't be simply broken down into a bunch of independent components. No fucking way. One or the other had to go. So after publically promising to support OpenDoc with great fanfare, and hiring the CyberDog team away from the already poor shrivled Apple, Netscape resolutely shot Old Yeller: they killed CyberDog, thus driving the last nail in the coffin of OpenDoc, and summarily fucking both Apple and IBM.

Sun observed OpenDoc's demise and the resulting fallout with the bearded delight of Osoma bin Laden watching CNN, because they wanted to promote their "100% pure" fundamentalist religion of JavaBeans (which at the time only existed as a widely announced name, and wasn't event designed yet) as the one alternative component framework to go up against ActiveX. But OpenDoc was in the way, so they danced on its grave when it died.

Then there was the time that Netscape hired a bunch of former NeXT guys, who had learned Java and decided to implement a NeXTStep-like toolkit in it. It worked really well, and looked really good, so Netscape hired those guys right up, named it "IFC" for "Internet Foundation Classes" so as to position it against MFC "Microsoft Foundation Classes", and announced that IFC was going to be the official "100% Pure Java" cross platform write once debug everywhere bla bla bla widget component toolkit for Netscape.

But the idea of another Java toolkit that wasn't vapourware spooked Sun, who was still vaporising their plans for JavaBeans and didn't want IFC taking away any of their media attention and mind share.

Sun was afraid of IFC because it had such a great name (nothing about the architecture mattered, except that it was not JavaBeans). IFC was what you got when you took the widely successful Microsoft Foundation Classes, removed the Microsoft, and replaced it with Internet instead. Yes, that kind of thinking really floats the boats of marketing people.

Sun saw IFC as a threat, as long as it was not under their control, so they called in an old favor they did Netscape, when they let them use the holy name "Java" to brand their scripting language that really didn't have anything to do with Java.

So Sun called in the "JavaScript" name favor, and Netscape turned IFC over to Sun in order to be "migrated" and "readjusted" to JavaBeans. Which really means they just disposed of the body, but stored the name away safely for later use.

Anyway, after all that, you can see why I have absolutely no faith in what the religiously anti-Microsoft zealouts come up with. Because their thinking is so clouded by their warped little models of the world, that no matter how good their technology is, they will destroy it for petty, stupid reasons.

Disclaimer: This is all my own warped and interpreted view of the world from my own perspective, as an ex-Sun-employee with an axe to grind, and other undocumented perspectives that I won't go into now, to protect my informers. Take it as fiction if you like.

The part about pie menus isn't fiction, though. You can download the free open source, documentation and demos at:

http://www.piemenu.com

The JavaScript pie menus for Internet Explorer 5.5 on Windows are at:

http://www.piemenu.com/JavaScriptPieMenus.html

And if you don't believe that pie menus are faster and more reliable than linear menus, you can prove it to yourself by playing the game "Fasteroids", and read all the source code if you don't trust me.

http://www.piemenu.com/fasteroids.html

As I said, it requires Internet Explorer 5.5 on Windows. But that was the whole point of this discussion.

-Don