You assume SVG will continue to work well in Mozilla? Quickly it will break between version 0.99 and 1.0, and become so unreliable that it instantly crashed the entire browser. The graphics rendered used to be perfect. The resolution used to be highly scalable and the colors smooth and vivid. JavaScript used to run perfectly, and interactive SVG used to render and animate complex graphics like a bat out of hell.
But no longer. It just crashes Mozilla. So if you installed it before, make sure you uninstall it now, because otherwise you will be left wondering why your browser crashes all the time.
It will happen between the 0.99 and 1.0 releases, when you least suspect it. Upgrading Mozilla from 0.99 to 1.0 will cause it. Just when you thought everything was finally stable, SVG breaks. There are rumors of work-arounds to keep it from crashing, but none of them work. Eventually it will be unavoidable, and designers who wanted to use SVG and Mozilla and Linux will be forced to use Flash and Internet Explorer and Windows, and eventually support WVG, because they're much less trouble.
Here here. Adobe's SVG viewer used to work in Mozilla, and then Mozilla broke it by changing the signature of a method in their new XP-COM plug-in interface, without changing the UUID of the interface, which is a big no-no that breaks the rules of XP-COM. Why can't they follow their own rules? The interface wasn't frozen, but Standard Operating Procedure dictates that you absolutely must change the UUID when you change a method signature, and they did not.
The whole point of XP-COM was to keep this kind of stuff from happening, and it wouldn't have happened if Mozilla had followed their own rules. If they followed their own rules, Adobe's SVG viewer would still work fine, and Mozilla wouldn't crash when you looked at an SVG file.
The SVG viewer used to work fine in Mozilla, but after you upgrade Mozilla from 0.99 to 1.0, then Mozilla crashes whenever you look at an SVG file! And there is no fix in sight because Mozilla moved the bug number 133567 to "Evangelism", meaning they won't fix it even though Mozilla caused the problem by not following their own rules. So now the ball is in Adobe's court to decide if they care to ever trust Mozilla again, after having been screwed.
Let's talk about SVG in Mozilla. Yes I know Mozilla supports a subset of SVG now (but not by default), however it's got a long way to go before it's anywhere near the abilities of Adobe's SVG viewer plug-in.
Adobe's SVG viewer used to work in Mozilla on Linux, but not it no longer works, in post-0.99 version of Mozilla. Not because Adobe broke it, but because they trusted Mozilla enough to use one of their "unsupported" XP-COM interfaces, which Mozilla changed. [See Mozilla bug number 133567.]
Granted, Mozilla had warned Adobe that they might change the interfaces, which were not yet frozen. But Mozilla broke their side of the contract by neglecting to change the UUID of the interface, when they changed a method signature, which should be Standard Operating Procedure.
The whole point of using XP-COM (which is the COM-like plug-in system that Mozilla uses) is to protect against things like this happening. But Mozilla didn't play by the rules, and screwed Adobe after they'd already released their SVG viewer plug-in.
So everyone is screwed because Adobe's SVG viewer USED to run on Mozilla on Linux and Windows, but NOT ANY MORE. Mozilla's built-in SVG support is impressive and commendable and going in the right direction, but nowhere near enough to fill the void left behind when AdobeSVG just stopped working one day.
Mozilla moved the bug that ASVG crashes mozilla to "Evangelism", so now the ball's in Adobe's court to decide if they'll trust the Mozilla project again after having been burnt. Of course it was the Mozilla project's Overenthusiastic Evangelism that convinced Adobe to use the early plug-in interface in the first place. You have to appreciate the irony of fighting fire with fire.
In the perfect world, Adobe would have released a fix for this problem soon after the it was "Evangelized" to their attention. And I would like a pony with that. But in the real world, they're off on the next version of their SVG viewer, and don't want to think about the old version. You can get a beta of the new version for Windows, but it's unstable, and not supported on any other platform than Windows.
But if you're using Linux and want to use Adobe's SVG viewer, you have to sit around and wait, hoping that Adobe will get around to releasing the next version of their SVG viewer, and when they do it will support Linux. But there are no guarentees. The original SVG viewer for Linux was only released as beta, never officially released. And Adobe's been said to be back-pedaling on SVG and concentrating on other products.
Batik would be usable as an SVG viewer plug-in (not as efficient but almost as functional where it counts), but I haven't been able to get past the Java security restrictions to enable the ecmascript interpreter (rhino). Batik packaged as an SVG viewer browser applet (in a way that rhino worked, enabling dynamic svg) would go a long way towards rendering Adobe's proprietary
SVG viewer irrelevant. But I haven't been able to figure out how to get rhino to work in an applet, or find any examples of Batik running in an applet as an interactive SVG viewer. Squiggle is not what I mean by an applet.
If anyone from Adobe is reading, and actually cares about SVG: When will the next version of Adobe's SVG viewer come out, and will it support Mozilla, Linux and Mac OS/X, as well as Windows and Internet Explorer? Or has Abobe given up on SVG?
If nobody from Adobe has anything to say about this horrible problem, I will take it as more evidence supporting the sad but persistent rumors that Adobe is back pedaling and giving up on SVG.
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.
"Bad spec, Bad process, Bad engineering, Bad standardization process. What's not to hate?"
(It's about the XIE image processing extension, but I think it's a great summary of the whole X-Windows situation.)
My second favorite quote is about the so-called Security extension:
"Security
The Security extension was introduced to address the security issues of mixing trusted and untrusted clients on a single X server, according to compartmented mode workstation thinking of the early 1990's.
It is not clear at this date whether it serves any useful purpose in today's environments, though it may be useful in the case of shared display walls.
If you think its facilities are useful, please let your opinions be known, along with concrete examples of real circumstances where it is helpful."
It is not clear at this date whether security serves any useful purpose in today's environments.
What's not to hate? Pass the hexkey and the MIT-MAGIC-COOKIE-1!
I've suggested that a couple times in the past on the xpert mailing list and comp.windows.x (13 and 16 years ago respectively)...
You could have a standard format for describing menus (xml is the obvious choice now but wasn't around at the time), that applications could install on the desktop, that would be tracked and managed locally (by a separate menu manager or more likely merged into the window manager, to maintain a consistent look and feel).
It's slow, inefficient and wasteful of system resources for menus to track over the network. It would be much easier and more consistent if all menus were locally rendered and tracked quickly with the same look and feel, and the user could select which way they wanted all menus to be rendered. If you can change the window frames by changing window managers, why should't you be able to do the same thing with menus?
Changing the look an feel of all menus in the system was easy to do with the NeWS window system, because all the menus ran locally in the window server, and shared the same code. So it was simple to change all linear menus to pie menus, put tabs on all window frames, or anything else.
If nobody's fixed this problem with X in 16 years, there must be a reason.
To quote The X-Windows Disaster:
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
-Don
From: Don Hopkins (don@BRILLIG.UMD.EDU)
Subject: Window Managers and Client Menus
Newsgroups: comp.windows.x
Date: 1989-09-19 09:08:21 PST
I think it's a pretty good idea to have the window manager, or some
other process running close to the server, handle all the menus.
Window managment and menu managment are separate functions, but it
would be a real performance win for the window and the menu manager to
reside in the same process. There should be options to deactivate
either type of managment, so you could run, say, a motif window
manager, and an open look menu manager at the same time. But I think
that in most cases you'd want the uniform user interface, and the
better performance, that you'd get by having both in one process.
I think it would be possible to implement something like this with the
NDE window manager in X11/NeWS. It's written in object oriented
PostScript, based on the tNt toolkit, and runs as a light weight
processes inside the NeWS server. This way, selecting from a menu
that invokes a window managment function only involves one process
(the xnews server), instead of three (the x server and the two
"outboard" managers), with all the associated overhead of paging, ipc,
and context switching.
Here's a message on a related subject that I sent to xpert a couple
years back (before I'd heard of the ICCCM). I never did get much
response, except that one person pointed out that that was precisely
the problem that NeWS was designed to solve.;-)
c(-; Once were done forging the menu manager standard, how about we
do text editors, huh?)
-Don
Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins <brillig.umd.edu!don@harvard>
To: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?
Marvin Solomon) writes:
What's the solution? I think it is to get rid of the idea of window
manager as a separate process, and build "window-manager" functions
into all windows.
That scares me. Wouldn't we then have the problem that suntools has
where the suntool binaries are huge? On my sun 3/50 the suntools
program itself is 728 blocks and the various other tools that run
under suntools are 952 blocks. Yuck.
How about setting up some sort of standard? For example, all window
The only way I could see Y going much of anywhere is if it allowed you to run X apps too.
You can run X-Windows applications on Windows, using Cygwin/X.
Why would you need any more backwards compatibility than that?
There is absolutely no need for a new window system to be backwards compatible with X in any way at all. Just run an X server in a window. Seal it off into its own minor sub-process, and don't let it pollute the design of another window system.
There are just too many damn X apps out there.
Compared to what? There are hardly any X apps out there, compared to the number of Windows apps. Most of the X apps out there have sucky user interfaces, or are trivial, or use a toolkit that's portable anyway. Don't let xcalc hold you back from doing something new.
There are a few reasonably common datatypes for which there is no good native plugin available (fewer and fewer as the months go by).
Let's talk about SVG. Yes I know Mozilla supports a subset of SVG now (but not by default), however it's got a long way to go before it's anywhere near the abilities of Adobe's SVG viewer plug-in.
Jim's wording is ironic because Adobe's SVG viewer used to work in Mozilla on Linux, but not it no longer works, in post-0.99 version of Mozilla. Not because Adobe broke it, but because they trusted Mozilla enough to use one of their "unsupported" XP-COM interfaces, which Mozilla changed. [See Mozilla bug number 133567.]
Granted, Mozilla had warned Adobe that they might change the interfaces, which were not yet frozen. But Mozilla broke their side of the contract by neglecting to change the UUID of the interface, when they changed a method signature, which should be Standard Operating Procedure.
The whole point of using XP-COM (which is the COM-like plug-in system that Mozilla uses) is to protect against things like this happening. But Mozilla didn't play by the rules, and screwed Adobe after they'd already released their SVG viewer plug-in.
So everyone is screwed because Adobe's SVG viewer USED to run on Mozilla on Linux and Windows, but NOT ANY MORE. Mozilla's built-in SVG support is impressive and commendable and going in the right direction, but nowhere near enough to fill the void left behind when AdobeSVG just stopped working one day.
Mozilla moved the bug that ASVG crashes mozilla to "Evangelism", so now the ball's in Adobe's court to decide if they'll trust the Mozilla project again after having been burnt. Of course it was the Mozilla project's Overenthusiastic Evangelism that convinced Adobe to use the early plug-in interface in the first place. You have to appreciate the irony of fighting fire with fire.
In the perfect world, Adobe would have released a fix for this problem soon after the it was "Evangelized" to their attention. And I would like a pony with that. But in the real world, they're off on the next version of their SVG viewer, and don't want to think about the old version. You can get a beta of the new version for Windows, but it's unstable, and not supported on any other platform than Windows.
But if you're using Linux and want to use Adobe's SVG viewer, you have to sit around and wait, hoping that Adobe will get around to releasing the next version of their SVG viewer, and when they do it will support Linux. But there are no guarentees. The original SVG viewer for Linux was only released as beta, never officially released. And Adobe's been said to be back-pedaling on SVG and concentrating on other products.
Batik would be usable as an SVG viewer plug-in (not as efficient but almost as functional where it counts), but I haven't been able to get past the Java security restrictions to enable the emcascript interpreter (rhino). Batik packaged as an SVG viewer browser applet (in a way that rhino worked, enabling dynamic svg) would go a long way towards rendering Adobe's proprietary
SVG viewer irrelevant. But I haven't been able to figure out how to get rhino to work in an applet, or find any examples of Batik running in an applet as an interactive SVG viewer. Squiggle is not what I mean by an applet.
Here is my solution to making the X-Windows desktop more productive and user friendly:
YesTool, a GUI interface to the classic powerful Unix utility "yes", written by the great hacker and University of Maryland alumni David MacKenzie!
YesTool will be totally user configable, just like the permissive command-line "yes". It will be written in object oriented reusable code using parameterizable C++ templates, so you can easily subclass it to make your own tools like NoTool, MaybeTool and ExecutiveDecisionMakerTool.
It will support drag-and-drop in single-answer or streaming mode. Also an emacs support package is in the works, with a special command called "psychoanalyze-yes"! And of course it will support gestures, and video input so you can nod and shake your head.
For more information on "yes", type "man yes". If you don't have enough men in your life, type "yes man".
I've written up a design spec in Star Open Office, made some concept screen mock-ups in Gimp, hacked up a prototype in GTK-Perl, but I still just can't seem to get drag-and-drop to work on X-Windows. I'm going to put the prototype up on SourceForge so everyone else can contribute, as soon as I can figure out how to get the damn autoconf file to work.
I consider programming languages to be user interfaces for programmers, so many of the same design principles apply. Perl, with its fractal syntactic surface area, is more like a flakey handwriting recognition system, while Python is more like pie menus. Perl gives you many different way to do anything, none better than the other, and all ugly. Python's ideal is that "There should be one-- and
preferably only one -- obvious way to do it." That's why Python is so much easier to learn, read and maintain than Perl.
Advice to people implementing gesture recognition systems: "In the face of ambiguity, refuse the temptation to guess."
-Don
The Zen of Python (by Tim Peters)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Here is the pseudo-mathematical argument that pie menus are better than gestures:
Consider the concept of "gesture space": all possible gestures you can make with the mouse, between pressing and releasing the button, touching the screen with a pen and lifting the pen, or whatever.
The area of gesture space is infinite, but it can be divided up between valid gestures and invalid gestures. And you can compare the relative sizes of the gesture space areas that each gesture occupies. Some gestures are easier than others, because they occupy a large proportion of gesture space.
Typical gesture systems, like handwriting recognition, only cover a small percentage of gesture space. Most gestures are invalid. If you press down the button and wiggle around randomly, it's likely that will be an invalid gesture.
You also have to consider the distinction between different gestures. How different are they from each other? How well are they seperated from each other in gesture space?
Handwriting recognizers have a hard time discriminating between the lowercase letters "u" and "n", because they are close to each other in gesture space, and the demarcation between them is an arbitrary gray area. There is no solid line you can draw between what's a valid "n" and what's a valid "u".
On the other hand, pie menus totally saturate 100% of gesture space, dividing it up evenly and unambiguously between gestures. Any gesture is a well defined pie menu selection. This is because pie menus depend only on the direction between the endpoints of the gesture, not the actual path between the endpoints.
Pie menus give you the ability to reselect a different item and correct errors after you've started a pie menu selection. The fact that pie menus allow reselection is extremely important for their ease-of-use and trustability. It gives users much more confidence about using them, that they don't have about conventional gesture recognition. Pie menus are forgiving where gestures are not.
Each of the different pie menu gestures are optimally separated from each other. All gestures are distinct and don't have ambiguous overlapping gray regions between them like the difference between "n" and "u'.
Since the interpretation of a pie menu gesture is so well defined (not by the ouput of fuzzy logic or hidden markov models or neural nets, but by simple visually obvious geometry), it's easy for the user to understand and predict how the computer will interpret the gesture. But conventional gesture recognition systems are complex, unpredictable black boxes.
Users can't confidently use "mouse ahead" or gestures unless they can trust that the computer will interpret them properly. Pie menus can be trusted in a way that gestures can't. Even if invisible gestures were easy to learn like pie menus, they still wouldn't be easy to trust.
You're totally missing the point. Pie menus teach you the gestures, but they're also useful if you haven't learned the gestures yet.
Without pie menus, you have to learn the gestures some other way, like reading manuals, or watching educational videos, which is why gestures are inherently harder to learn than pie menus.
Mousing ahead through pie menus is a gesture, so pie menus are not "inherently slower" than gestures. Pie menus teach you to use the gestures, while they're still useful before you have learned the gestures.
You're inherently wrong when you say that pie menus are inherently slower than mouse gestures.
And you're ignoring the fact that mouse gestures are inherently harder to learn than pie menus.
You hit the nail on the head. Pie menus are "self revealing" because they prompt you with the available options when you don't know them well enough to "mouse ahead". In comparison, pure gesture based systems are invisible and hard to learn. And they make it too easy to accidentally issue unintended commands. Pie menus are much more reliable, because they allow you to correct your selection at any time before confirming it with a click, while gesture systems don't permit "in flight reselection": once you've started to make the wrong gesture, you're screwed. Pie menus enable novice users to "rehearse" the mouse-ahead gesture by prompting them with directions, so you can learn to use the gestures you need smoothly at your own pace, instead of being forced to memorize a bunch of invisible gestures right off the bat.
Ted Selker invented and developed the red "joy button" keyboard clitoris into a product (the thinkpad) while he was at IBM Almaden Research Center.
According to IBM's ad in Time magazine, it was "so hot we had to make it red". Ted made an even hotter version in the lab, that had TWO "joy buttons" -- one for each hand!
ONE joy button was so hot they made it red, but the TWO nipple keyboard was too hot even for IBM management to handle.
They tried to come up with a keyboard that was robust enough to withstand all the abuse and body fluids afforded by the two nipples, by experimenting with various sizes of silicon implants and drainage troughs. But users were so enthustiastic that they quickly wore them out, popped the implants, broke their hinges, and busted their nuts.
IBM tried as hard as they could to develop a drool and semen proof keyboard strong enough to support two joy buttons, but it was just too expensive to produce. Rumor has it that Lou Gerstner keeps the only surviving dual-nipple prototype installed on a thinkpad in his executive washroom.
After having his life's work turned in to a corporate executive masturbation device, Ted left IBM to work at MIT Media Labs, where they appreciate the potential applications of digital masturbation to corporate executive sponsors. c(-;
What's wrong with quoting something I wrote myself, if it's still true after 10 years? It's not an old slashdot posting -- it was published in a book that's now out of print (the Unix Haters Handbook).
You don't know enough about X to address any of the facts in my posting, so you attack my sources (which happens to be myself). Are you saying that it's "sad" for anyone to write about their own experiences on slashdot? Or that it's only fair to quote other people? Or are you saying I should't quote myself because I'm not qualified to hold an opinion about X-Windows?
Please justify your own opinion, Blackbolt: How much experience do you have developing software for X-Windows? Can you counter my points by sharing some of your own first-hand experiences, to hold up of your end of the argument instead of attacking my sources? Or would that be too "sad"?
I attended the first X Window System Users and Developers Conference in January of 1987, and hacked X10 window managers before that. I though X10 was cool, simple and elegant (though it had serious flaws), but it all went downhill with X11.
X-Windows simply sucks, and the fact that it hasn't stopped sucking after all these years does not bode well for its future. It's the monkey on the back of Linux, that prevents it from appealing to a wide market and succeeding on the desktop.
I would like to propose that all GUI designers eschew anything actually resembling visible display of an interface, and simply ship a library, and a loose 'conceptual' discussion of what effects the display should provoke, according to a psychological or astrological model of the user's personality (Jungian, Freudian, or Dosteyevskian), their latitutude and longitude, and blood sugar levels. It should be completely up to the user to specify a display (I believe POSEUR is addressing the shipment of design-free GUI design for user-transparent configuration: open, scalable, and extensible, the problem is almost PN complete).
Sample KIT (using a paradigm of an application which extracts semantic nets from French Literature in Translation):
1. Parameters: none
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's/Utopia/, and a well-fingered/Neuromancer/
4. One copy of Italian Vogue Summer collection '82
5. Default Interface Processor (DIP) to generate a user-configurable default interface upon which one can generate proposed target 'research' examples.
6. One copy of USA Today and Time (tm) magazine to be used for sample non-default graphical layout guidelines.
+ XYmorph (tm): a new easy-to-use open extensible and scalable system for randomly per/mutating user interfaces. A manifestation of the concept of both stimulated healling and scatter-brain i/o in order to most quickly reach suboptimal interface design with the least amount of effort on the part of the designer or the user.
+ Quagmire: a CD-rom collection of over 4 quadrillion possible interfaces generated for a Unix(tm) open, extensible, and scalable graphical C-shell-feel-good-alike system. Meets ANSI, K&R, A&P, S&H
+ and other stamped standards in continental US.
+ boraX: a user-configurable interface cleanser. Open, extensible, and scalable, it removes all traces of design constraint from simple structured systems and creates flat-design mazelike idio(syncratic/pathic/syncretic) systems of fresh and clean code.
Sample concept discussion:
The pointer (I hesitate to use such a loaded word: for users who object to object orientation and simplistic Western-philosophy views of dichotomatic (not diatomaceous or deciduous, though wooden feelings might be appropriate for Environmentally friendly X displays) subject/object distinctions might prefer to discuss 'object compliment', or even 'compliment' (as in Complimentary beverage or Complimentary sugar-coated dry-roasted 100% genuine Virgina grown goober peas just the way they grew them in olden times) in order to provoke an awareness and create a more extensible scalable and transparent user environment for those who aren't really worried about domain/range distinctions in disjunctive noun mappings) should respond to a click (which is to say a simple tap, of varying duration depending upon the physical capabilities and inclinations of those who might be inclined to acutally depress the open, extensible, and scalable button on a mouse (though those of us who object to laboratory research mechanomorphization of living entities prefer to call 'mice' 'clickers', thus preserving the dignity of what we all must recognize is part of a larger Gaiaen web of life (which is, I must remark, open, scalable, and extensible, life that is, not the mouse) and metonymically convolving form and function into the open, scalable and extensible nomenclature of X).
XBorges.
One longs for the day when the responsibility of programming computers falls squarely on the shoulders of the users, where it belongs; they are provided with a set of infinitely configurable instruction codes, on an open, extensible, and scalable n-bit bus, and their task before setting upo
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff'sHyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that
X is extremely device dependent because all X graphics are specified in
piel coordinates. graphics drawn on different resulution screens come out
at different sizes, so you have to scale all the coordinates yourself if
you want to draw at a certain size. Not all screens have square pixels:
unless you don't mind rectangular squares and oval circles, you also have
to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because
of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square
with XFillRectangle, it fills the 100 pixels you expect. But you get extra
bonus pixels when you pass the same arguments to XDrawRectangle,
because it actually draws an 11x11 square, hanging out one pixel below and
to the right!!! If you find this hard to believe, look it up in the X manual
yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how
easy it is to add 1 to the x and y position of the filled rectangle, while
subtracting 1 from the width and height to compensate, so it fits neatly
inside the outline. Then it points out that in the case of arcs, however,
this is a much more difficult proposition (probably impossible in a portable
fashion). This means that portably filling and stroking an arbitrarily
scaled arc without overlapping or leaving gaps is an intractable problem
when using the X Window System. Think about that. You can't even draw a
proper rectangle with a thick outline, since the line width is specified
in unscaled pixel units, so if your display has rectangular pixels, the
vertical and horizontal lines will have different thicknesses enen though
you scaled the rectangle corner coordinates to compensate for the aspect
ratio.
The color situation is a total flying circus. The X approach to device independence
is to treat everything like a MicroVAX framebuffer on acid. A truly portable
X application is required to act like the persistent customer in Monty Python's
Cheese Shop sketch, or a grail seeker in Monty Python
and the Holy Grail. Even the simplest applications must answer many
difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
BlackPixel(display, DefaultScreen(display)),
WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0;/* Black. */ /* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display)); /* AAAYYYYEEEEE!! */
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST? /* Is that a SubStructureRedirectMask or a ResizeRedirectMask? */
WHAT??! HOW AM I SUPPOSED TO KNOW THAT?
AAAAUUUGGGHHH!!!! (server dumps core & falls into the chasm)
On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.
The most that can be said about the lowest-common-denominator approach that X takes to graphics is that it levels the playing field, allowing incredibly stupid companies to jump on the bandwagon and sell obsolete junk that's just as unusable as high-end brand-name workstations.
So somebody thinks it would be a great idea to double buffer every window, in an attempt to make X look cool like a Mac. First, please explain HOW this increases usability? How many megabytes and mips will displaying a clock require, then? And how much better will the clock tell the time? And how many Commodore 64s would that take?
How to make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC
If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that.
- Marus J. Ranum, Digital Equipment Corporation
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.
X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
In the Unix-Haters book, I wrote about ICCCM in the X-Windows Disaster chapter:
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
- Jamie Zawinski
The following classic article should be required reading for anyone studying user interface design or drug abuse prevention. It documents the effects of cocaine on user interface design. There is no other logical explaination for what happened to QuickTime at Apple. The lesson learned from this fiasco is that Apple's UI designers should put down their crack pipe and step away from the computer.
QuickTime is a lost cause. Apple has invested millions of dollars in sabotaging their own product. Use QuickTime at your own peril, only if you're as self destructive as Apple.
You should now use the term "The Window System Formerly Known as X", unless you've installed the special font, in which case you can use the symbol that has no verbal pronunciation or spelling.
Slashdot Mirror
http://catalog.com/hopkins/images/pizzatool.gif (screen snapshot)
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool (source code)
ftp://ftp.uu.net/graphics/NeWS/tnt/pizzatool.6 (manual)
-Don
But no longer. It just crashes Mozilla. So if you installed it before, make sure you uninstall it now, because otherwise you will be left wondering why your browser crashes all the time.
It will happen between the 0.99 and 1.0 releases, when you least suspect it. Upgrading Mozilla from 0.99 to 1.0 will cause it. Just when you thought everything was finally stable, SVG breaks. There are rumors of work-arounds to keep it from crashing, but none of them work. Eventually it will be unavoidable, and designers who wanted to use SVG and Mozilla and Linux will be forced to use Flash and Internet Explorer and Windows, and eventually support WVG, because they're much less trouble.
-Don
The SVG viewer used to work fine in Mozilla, but after you upgrade Mozilla from 0.99 to 1.0, then Mozilla crashes whenever you look at an SVG file! And there is no fix in sight because Mozilla moved the bug number 133567 to "Evangelism", meaning they won't fix it even though Mozilla caused the problem by not following their own rules. So now the ball is in Adobe's court to decide if they care to ever trust Mozilla again, after having been screwed.
-Don
Adobe's SVG viewer used to work in Mozilla on Linux, but not it no longer works, in post-0.99 version of Mozilla. Not because Adobe broke it, but because they trusted Mozilla enough to use one of their "unsupported" XP-COM interfaces, which Mozilla changed. [See Mozilla bug number 133567.]
Granted, Mozilla had warned Adobe that they might change the interfaces, which were not yet frozen. But Mozilla broke their side of the contract by neglecting to change the UUID of the interface, when they changed a method signature, which should be Standard Operating Procedure.
The whole point of using XP-COM (which is the COM-like plug-in system that Mozilla uses) is to protect against things like this happening. But Mozilla didn't play by the rules, and screwed Adobe after they'd already released their SVG viewer plug-in.
So everyone is screwed because Adobe's SVG viewer USED to run on Mozilla on Linux and Windows, but NOT ANY MORE. Mozilla's built-in SVG support is impressive and commendable and going in the right direction, but nowhere near enough to fill the void left behind when AdobeSVG just stopped working one day.
Mozilla moved the bug that ASVG crashes mozilla to "Evangelism", so now the ball's in Adobe's court to decide if they'll trust the Mozilla project again after having been burnt. Of course it was the Mozilla project's Overenthusiastic Evangelism that convinced Adobe to use the early plug-in interface in the first place. You have to appreciate the irony of fighting fire with fire.
In the perfect world, Adobe would have released a fix for this problem soon after the it was "Evangelized" to their attention. And I would like a pony with that. But in the real world, they're off on the next version of their SVG viewer, and don't want to think about the old version. You can get a beta of the new version for Windows, but it's unstable, and not supported on any other platform than Windows.
But if you're using Linux and want to use Adobe's SVG viewer, you have to sit around and wait, hoping that Adobe will get around to releasing the next version of their SVG viewer, and when they do it will support Linux. But there are no guarentees. The original SVG viewer for Linux was only released as beta, never officially released. And Adobe's been said to be back-pedaling on SVG and concentrating on other products.
Batik would be usable as an SVG viewer plug-in (not as efficient but almost as functional where it counts), but I haven't been able to get past the Java security restrictions to enable the ecmascript interpreter (rhino). Batik packaged as an SVG viewer browser applet (in a way that rhino worked, enabling dynamic svg) would go a long way towards rendering Adobe's proprietary SVG viewer irrelevant. But I haven't been able to figure out how to get rhino to work in an applet, or find any examples of Batik running in an applet as an interactive SVG viewer. Squiggle is not what I mean by an applet.
If anyone from Adobe is reading, and actually cares about SVG: When will the next version of Adobe's SVG viewer come out, and will it support Mozilla, Linux and Mac OS/X, as well as Windows and Internet Explorer? Or has Abobe given up on SVG?
If nobody from Adobe has anything to say about this horrible problem, I will take it as more evidence supporting the sad but persistent rumors that Adobe is back pedaling and giving up on SVG.
-Don
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.
-Don
(It's about the XIE image processing extension, but I think it's a great summary of the whole X-Windows situation.)
My second favorite quote is about the so-called Security extension:
It is not clear at this date whether security serves any useful purpose in today's environments.What's not to hate? Pass the hexkey and the MIT-MAGIC-COOKIE-1!
X-Windows: Even your dog won't like it.
-Don
You could have a standard format for describing menus (xml is the obvious choice now but wasn't around at the time), that applications could install on the desktop, that would be tracked and managed locally (by a separate menu manager or more likely merged into the window manager, to maintain a consistent look and feel).
It's slow, inefficient and wasteful of system resources for menus to track over the network. It would be much easier and more consistent if all menus were locally rendered and tracked quickly with the same look and feel, and the user could select which way they wanted all menus to be rendered. If you can change the window frames by changing window managers, why should't you be able to do the same thing with menus?
Changing the look an feel of all menus in the system was easy to do with the NeWS window system, because all the menus ran locally in the window server, and shared the same code. So it was simple to change all linear menus to pie menus, put tabs on all window frames, or anything else.
If nobody's fixed this problem with X in 16 years, there must be a reason.
To quote The X-Windows Disaster: Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
-Don
From: Don Hopkins (don@BRILLIG.UMD.EDU)
Subject: Window Managers and Client Menus
Newsgroups: comp.windows.x
Date: 1989-09-19 09:08:21 PST
I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process.
I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching.
Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-)
c(-; Once were done forging the menu manager standard, how about we do text editors, huh?)
-Don
Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins <brillig.umd.edu!don@harvard>
To: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?
There is absolutely no need for a new window system to be backwards compatible with X in any way at all. Just run an X server in a window. Seal it off into its own minor sub-process, and don't let it pollute the design of another window system.
Compared to what? There are hardly any X apps out there, compared to the number of Windows apps. Most of the X apps out there have sucky user interfaces, or are trivial, or use a toolkit that's portable anyway. Don't let xcalc hold you back from doing something new.-Don
Jim's wording is ironic because Adobe's SVG viewer used to work in Mozilla on Linux, but not it no longer works, in post-0.99 version of Mozilla. Not because Adobe broke it, but because they trusted Mozilla enough to use one of their "unsupported" XP-COM interfaces, which Mozilla changed. [See Mozilla bug number 133567.]
Granted, Mozilla had warned Adobe that they might change the interfaces, which were not yet frozen. But Mozilla broke their side of the contract by neglecting to change the UUID of the interface, when they changed a method signature, which should be Standard Operating Procedure.
The whole point of using XP-COM (which is the COM-like plug-in system that Mozilla uses) is to protect against things like this happening. But Mozilla didn't play by the rules, and screwed Adobe after they'd already released their SVG viewer plug-in.
So everyone is screwed because Adobe's SVG viewer USED to run on Mozilla on Linux and Windows, but NOT ANY MORE. Mozilla's built-in SVG support is impressive and commendable and going in the right direction, but nowhere near enough to fill the void left behind when AdobeSVG just stopped working one day.
Mozilla moved the bug that ASVG crashes mozilla to "Evangelism", so now the ball's in Adobe's court to decide if they'll trust the Mozilla project again after having been burnt. Of course it was the Mozilla project's Overenthusiastic Evangelism that convinced Adobe to use the early plug-in interface in the first place. You have to appreciate the irony of fighting fire with fire.
In the perfect world, Adobe would have released a fix for this problem soon after the it was "Evangelized" to their attention. And I would like a pony with that. But in the real world, they're off on the next version of their SVG viewer, and don't want to think about the old version. You can get a beta of the new version for Windows, but it's unstable, and not supported on any other platform than Windows.
But if you're using Linux and want to use Adobe's SVG viewer, you have to sit around and wait, hoping that Adobe will get around to releasing the next version of their SVG viewer, and when they do it will support Linux. But there are no guarentees. The original SVG viewer for Linux was only released as beta, never officially released. And Adobe's been said to be back-pedaling on SVG and concentrating on other products.
Batik would be usable as an SVG viewer plug-in (not as efficient but almost as functional where it counts), but I haven't been able to get past the Java security restrictions to enable the emcascript interpreter (rhino). Batik packaged as an SVG viewer browser applet (in a way that rhino worked, enabling dynamic svg) would go a long way towards rendering Adobe's proprietary SVG viewer irrelevant. But I haven't been able to figure out how to get rhino to work in an applet, or find any examples of Batik running in an applet as an interactive SVG viewer. Squiggle is not what I mean by an applet.
-Don
YesTool, a GUI interface to the classic powerful Unix utility " yes ", written by the great hacker and University of Maryland alumni David MacKenzie!
YesTool will be totally user configable, just like the permissive command-line " yes ". It will be written in object oriented reusable code using parameterizable C++ templates, so you can easily subclass it to make your own tools like NoTool, MaybeTool and ExecutiveDecisionMakerTool. It will support drag-and-drop in single-answer or streaming mode. Also an emacs support package is in the works, with a special command called "psychoanalyze-yes"! And of course it will support gestures, and video input so you can nod and shake your head.
For more information on " yes ", type "man yes". If you don't have enough men in your life, type "yes man".
I've written up a design spec in Star Open Office, made some concept screen mock-ups in Gimp, hacked up a prototype in GTK-Perl, but I still just can't seem to get drag-and-drop to work on X-Windows. I'm going to put the prototype up on SourceForge so everyone else can contribute, as soon as I can figure out how to get the damn autoconf file to work.
-Don
Advice to people implementing gesture recognition systems: "In the face of ambiguity, refuse the temptation to guess."
-Don
The Zen of Python (by Tim Peters)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Consider the concept of "gesture space": all possible gestures you can make with the mouse, between pressing and releasing the button, touching the screen with a pen and lifting the pen, or whatever.
The area of gesture space is infinite, but it can be divided up between valid gestures and invalid gestures. And you can compare the relative sizes of the gesture space areas that each gesture occupies. Some gestures are easier than others, because they occupy a large proportion of gesture space.
Typical gesture systems, like handwriting recognition, only cover a small percentage of gesture space. Most gestures are invalid. If you press down the button and wiggle around randomly, it's likely that will be an invalid gesture.
You also have to consider the distinction between different gestures. How different are they from each other? How well are they seperated from each other in gesture space?
Handwriting recognizers have a hard time discriminating between the lowercase letters "u" and "n", because they are close to each other in gesture space, and the demarcation between them is an arbitrary gray area. There is no solid line you can draw between what's a valid "n" and what's a valid "u".
On the other hand, pie menus totally saturate 100% of gesture space, dividing it up evenly and unambiguously between gestures. Any gesture is a well defined pie menu selection. This is because pie menus depend only on the direction between the endpoints of the gesture, not the actual path between the endpoints.
Pie menus give you the ability to reselect a different item and correct errors after you've started a pie menu selection. The fact that pie menus allow reselection is extremely important for their ease-of-use and trustability. It gives users much more confidence about using them, that they don't have about conventional gesture recognition. Pie menus are forgiving where gestures are not.
Each of the different pie menu gestures are optimally separated from each other. All gestures are distinct and don't have ambiguous overlapping gray regions between them like the difference between "n" and "u'.
Since the interpretation of a pie menu gesture is so well defined (not by the ouput of fuzzy logic or hidden markov models or neural nets, but by simple visually obvious geometry), it's easy for the user to understand and predict how the computer will interpret the gesture. But conventional gesture recognition systems are complex, unpredictable black boxes.
Users can't confidently use "mouse ahead" or gestures unless they can trust that the computer will interpret them properly. Pie menus can be trusted in a way that gestures can't. Even if invisible gestures were easy to learn like pie menus, they still wouldn't be easy to trust.
-Don
Without pie menus, you have to learn the gestures some other way, like reading manuals, or watching educational videos, which is why gestures are inherently harder to learn than pie menus.
Mousing ahead through pie menus is a gesture, so pie menus are not "inherently slower" than gestures. Pie menus teach you to use the gestures, while they're still useful before you have learned the gestures.
You're inherently wrong when you say that pie menus are inherently slower than mouse gestures. And you're ignoring the fact that mouse gestures are inherently harder to learn than pie menus.
-Don
-Don
-Don
According to IBM's ad in Time magazine, it was "so hot we had to make it red". Ted made an even hotter version in the lab, that had TWO "joy buttons" -- one for each hand!
ONE joy button was so hot they made it red, but the TWO nipple keyboard was too hot even for IBM management to handle.
They tried to come up with a keyboard that was robust enough to withstand all the abuse and body fluids afforded by the two nipples, by experimenting with various sizes of silicon implants and drainage troughs. But users were so enthustiastic that they quickly wore them out, popped the implants, broke their hinges, and busted their nuts.
IBM tried as hard as they could to develop a drool and semen proof keyboard strong enough to support two joy buttons, but it was just too expensive to produce. Rumor has it that Lou Gerstner keeps the only surviving dual-nipple prototype installed on a thinkpad in his executive washroom.
After having his life's work turned in to a corporate executive masturbation device, Ted left IBM to work at MIT Media Labs, where they appreciate the potential applications of digital masturbation to corporate executive sponsors. c(-;
-Don
You don't know enough about X to address any of the facts in my posting, so you attack my sources (which happens to be myself). Are you saying that it's "sad" for anyone to write about their own experiences on slashdot? Or that it's only fair to quote other people? Or are you saying I should't quote myself because I'm not qualified to hold an opinion about X-Windows?
Please justify your own opinion, Blackbolt: How much experience do you have developing software for X-Windows? Can you counter my points by sharing some of your own first-hand experiences, to hold up of your end of the argument instead of attacking my sources? Or would that be too "sad"?
I attended the first X Window System Users and Developers Conference in January of 1987, and hacked X10 window managers before that. I though X10 was cool, simple and elegant (though it had serious flaws), but it all went downhill with X11.
X-Windows simply sucks, and the fact that it hasn't stopped sucking after all these years does not bode well for its future. It's the monkey on the back of Linux, that prevents it from appealing to a wide market and succeeding on the desktop.
-Don
From: francis@ircam.fr (Joseph Francis)
I would like to propose that all GUI designers eschew anything actually resembling visible display of an interface, and simply ship a library, and a loose 'conceptual' discussion of what effects the display should provoke, according to a psychological or astrological model of the user's personality (Jungian, Freudian, or Dosteyevskian), their latitutude and longitude, and blood sugar levels. It should be completely up to the user to specify a display (I believe POSEUR is addressing the shipment of design-free GUI design for user-transparent configuration: open, scalable, and extensible, the problem is almost PN complete). Sample KIT (using a paradigm of an application which extracts semantic nets from French Literature in Translation):
1. Parameters: none /Utopia/, and a well-fingered /Neuromancer/
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's
4. One copy of Italian Vogue Summer collection '82
5. Default Interface Processor (DIP) to generate a user-configurable default interface upon which one can generate proposed target 'research' examples.
6. One copy of USA Today and Time (tm) magazine to be used for sample non-default graphical layout guidelines.
+ XYmorph (tm): a new easy-to-use open extensible and scalable system for randomly per/mutating user interfaces. A manifestation of the concept of both stimulated healling and scatter-brain i/o in order to most quickly reach suboptimal interface design with the least amount of effort on the part of the designer or the user.
+ Quagmire: a CD-rom collection of over 4 quadrillion possible interfaces generated for a Unix(tm) open, extensible, and scalable graphical C-shell-feel-good-alike system. Meets ANSI, K&R, A&P, S&H
+ and other stamped standards in continental US.
+ boraX: a user-configurable interface cleanser. Open, extensible, and scalable, it removes all traces of design constraint from simple structured systems and creates flat-design mazelike idio(syncratic/pathic/syncretic) systems of fresh and clean code.
Sample concept discussion:
The pointer (I hesitate to use such a loaded word: for users who object to object orientation and simplistic Western-philosophy views of dichotomatic (not diatomaceous or deciduous, though wooden feelings might be appropriate for Environmentally friendly X displays) subject/object distinctions might prefer to discuss 'object compliment', or even 'compliment' (as in Complimentary beverage or Complimentary sugar-coated dry-roasted 100% genuine Virgina grown goober peas just the way they grew them in olden times) in order to provoke an awareness and create a more extensible scalable and transparent user environment for those who aren't really worried about domain/range distinctions in disjunctive noun mappings) should respond to a click (which is to say a simple tap, of varying duration depending upon the physical capabilities and inclinations of those who might be inclined to acutally depress the open, extensible, and scalable button on a mouse (though those of us who object to laboratory research mechanomorphization of living entities prefer to call 'mice' 'clickers', thus preserving the dignity of what we all must recognize is part of a larger Gaiaen web of life (which is, I must remark, open, scalable, and extensible, life that is, not the mouse) and metonymically convolving form and function into the open, scalable and extensible nomenclature of X).
XBorges.
One longs for the day when the responsibility of programming computers falls squarely on the shoulders of the users, where it belongs; they are provided with a set of infinitely configurable instruction codes, on an open, extensible, and scalable n-bit bus, and their task before setting upo
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that
Myth: X is Device Independent
X is extremely device dependent because all X graphics are specified in piel coordinates. graphics drawn on different resulution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra bonus pixels when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion). This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's Cheese Shop sketch, or a grail seeker in Monty Python and the Holy Grail. Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display, DefaultScreen(display)), WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY? /* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
display = XOpenDisplay(unix:0);
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0;
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
/* Is that a SubStructureRedirectMask or a ResizeRedirectMask? */
display = XOpenDisplay(unix:0);
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
WHAT??! HOW AM I SUPPOSED TO KNOW THAT?
AAAAUUUGGGHHH!!!!
(server dumps core & falls into the chasm)
-Don Hopkins
On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.
The most that can be said about the lowest-common-denominator approach that X takes to graphics is that it levels the playing field, allowing incredibly stupid companies to jump on the bandwagon and sell obsolete junk that's just as unusable as high-end brand-name workstations.
-Don
-Don
From the X-Windows Disaster:
How to make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
-Don Hopkins
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
-Don Hopkins
http://digilander.libero.it/chiediloapippo/Enginee ring/iarchitect/qtime.htm
QuickTime is a lost cause. Apple has invested millions of dollars in sabotaging their own product. Use QuickTime at your own peril, only if you're as self destructive as Apple.
-Don
INSTRUCTIONS FOR THE USE OF THE "&ArtistFormerlyKnownAsPrince;" SYMBOL
-Don