Slashdot Mirror
Resources for Rolling Your Own Windowing System?
WalterGR asks: "There are plenty of resources available for writing operating systems, e.g. Tanenbaum's Modern Operating Systems, the Dinosaur Book, and countless web sites. For those of us who aren't interested in low-level issues, and prefer focusing on human-computer interaction, what resources are available for designing windowing systems (a la X Window)? Issues like the object hierarchy, event management, modularity, redefining behavior at runtime (e.g. for skins) etc. Any suggestions?"
Take a look at the object windowing libraries put out by several vendors. It should give you a good footing on developing your own object hierarchy.
As for not getting into 'low-level' stuff, you're SOL if you want to build an X-like system.
First you need to ask yourself if you really want to recreate the XWindows System or if you want to create a window manager like Enlightenment, fvwm, etc. If you want to recreate the years of work that has gone into X, that's your choice but I think you should look at creating a window manager, you'll probably get farther.
http://www.atai.org/guitool/
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
Anyways, the greatest documentation of all to learn form is, was, and always will be source code.
Ryan T. Sammartino
"Ancora imparo"
That windowing systems and HCI are distinct. Windowing systems is a component of HCI, but so is command line interfaces, voice interfaces, and graphical interfaces.
Windowing systems is one metaphor applied to graphical interfaces. HCI includes the concepts of learnability, consistent behavior, teachability, and useability.
I'm defining learnability as the capacity for the system to teach the user, and teachability is the capacity for the system to adapt to the user.
Windowing systems doesn't necessarily have anything to do with any of those four points unless the designer and developer choses to address those points. Themes and skins count as teachable, adaptable systems, but do not necessarily mean the system is useable, powerful, or capable.
GPL Deconstructed
rolling your own windows system?
I think I know what you guys were rolling before writing that bizarre headline.
The Slashdot Effect: A new for
People that have successfully built Windowing System are the people to ask. Odds are, there aren't more than 1% of /. readers that have successfully made an entire windowing system.
Also, check the code of successful, open source windowing systems...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Of course, MS's window system is a classic example of how to break all of the established rules about GUI design.
If you rool your own, don't copy the mistakes made by MS/Apple/Xerox. GUI research has come along way since those days. Alas, we never see the results because of the entrenched WIMP paridgm - which is very out moded.
In addition, many of the things learnt through WIMP have been successively undone my MS.
For example, menus at the top of the screen (ala MacOS) worked well because a user's motor memory it trained to select items. The functions become motor program - like learning to play a piano.
Unfortunately, this is broken if the menus change (e.g. MS's idea of hiding items and them bringing them back, moving them around etc.). It also doesn't work for menus on window titles - as you need to overload your visual system to select the menu to begin with. Only context and screen top menus retain the original design a pros of menus these days.
There are many many other examples like this. I sugest you find some books on human factors and learn how visual and motor systes work etc.
/..sig file not found - permission denied.
I've been working for about 4 years now on a graphical user interface for dos as a pet project, and have learned a great number of things. So many, in fact, that i'm in the middle (still) of rewriting it. If you're intreseted, the website is http://dwin.sf.net/ and is open sourced. When the new version comes out (or the next preview) one could use it to see how it all fits together. This would be better then trying to use XWin to learn how everything works because it is smaller, simplier and very OOP (which is great for windowing systems). And yes, most of /. will call me crazy for reinventing the GUI, but heck, i've learned so much about computers in doing it that it's been a real fun time.
-Jon Gentle(atrodo@atrodo.org)
There is not a lot of information beyond some of the linux toolkit developers or Xfree / X Group, simply because this is not a very large arena, and there just isn't enough interest in creating another interface for user applications(flamebait).
The problem is that when a user needs to write a program they have to be "aware" of your toolkit, or be unable to run on your machine.
The result of all this has become a very constrained community of developers creating tiny visual enhancements and having the community feed off their ideas. This has been going on for > 10 years, at least. Mac's are probably the most original designers of UI system, since most company's products mimmic their styles and design elements.
Bye!
No, please, not another windowing system. X11 is fine for most purposes and, if you need something is does not provide, write an extension. There are more than enough 'alternatives' that are either designed for niches, have never been finished or will never get a significant marekt share. They don't have any significant advantage, at least as a general window system, and they lack applications. And despite those people who claim that X11 is sooo bloated (usually because they see the memory usage and do not realize that most of the memory is taken by pixmaps that won't take less space in other solutions) there are proofs like TinyX and WeirdX.
Mainly, don't be boring. There is no shortage of windowing systems that do what everyone else is doing, with a few mostly useless features and some buzzword compliance added to distinguish themselves from the pack. The easiest thing in the world to do is make a second-rate clone of an existing system, and that won't do anyone any good.
If you want to see interesting and innovative interfaces, look at games. They are free to experiment and be unfamiliar, people even enjoy the exotic feeling of escape from the humdrum world of standard interfaces. Of course, there is more bad than good, but it's always that way where people are trying new things.
Okay, one reference: Ask Tog. Lots of good thoughts on interface design. One of his gripes stands out for me in particular: the importance of the corners of the screen in a mouse-based interface. You can always hit the corners without looking, and with a little practice, you can also hit things near the corners by "bouncing" off the corner. Radial menus out of the corners are probably the easiest thing in the world to hit reliably and quickly. Don't neglect the corners!
Of course, this goes right out if you switch to a pen. In a lot of ways, current interfaces are much better suited to pens than to mice.
Actually, it works well because it's easier and faster for the user to move a mouse to a large area (and one limited by the top of the screen) accurately, than it is to aim for a menu homed at the top of a window. "Muscle memory" has nothing to do with it, largely because it doesn't exist, although I agree that familiarity also makes it easier to use than an ever-changing menu system.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I think the best way to learn how X, for example works would be to use the wrox book on X Window programming and then see how that works and move from there. O'reilly also recently released a book about GUIs under the Mac platform. Also, does anyone know how microsoft does there GUI stuff? Gnome is great and all but it just seems to me that the windoes GUI is much better than gnome/kde. I dont want to start a war so i'll say that I'm a linux user nonetheless, but there must be a better way than X windows.
Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.
The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.
That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).
Microsoft's Research is pretty good...
These guys spend a lot of effort answering the kind of questions you're asking.
"Don't blame me, I voted for Kodos!"
I would also like to be able to summon some sort of Lisp console from any application. The Script-Fu console in the Gimp is pretty much what I'm thinking about. After learning the language of the system, a person could learn to automate, customize, and extend the functionality of every application.
My only political goal is to see to it that no political party achieves its goals.
after working nmap and then with nmapfe, i had the idea where you would write your tool as a native CLI base program but one which provided hooks for a gui over it. nmapfe simply, as far as i can understand, does this by using the GUI to construct the command and then when hit 'enter' running a system call. this approach could be further extended by providing some hooks into the native CLI program whereby a generic GUI tool could probe the tool to see what screens to present to the user.
for example, in the document-view setting, have the view class just generate some form of xml (glade-ish) so that this generic-runtime-gui-builder can query this command line too to build the gui for it. this is all so that each and every tool would have a commandline and a GUI in a very consistant fashion. also, most of the time, the huge GUI programs are just replicating the code for the GUI. this all could be in one generic GUI-runtime-builder.
i know this is all convoluted. i'm still trying to work it out in my head.
i did go as far as creating a 'browser' where you'd run this generic-window which then pulled the interface requested by the app into the main window using glade. just that bit is quite simple. but i'm still working on the rest of it...
I find the window-top menus easier myself, because they let me map application functions with a particular visual workspace on the screen, and I thus have to remember less state (what application am I inside of now?). Maybe my brain is a bit more "object oriented" than most. :)
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
#include
#include <rants/msvapple.h>
#include <rants/nextstep.h>
#include <slashdot/troll.h>
#include <stdio.h>
int main (int argc, char *argv[])
{
puts("Real programmers use curses");
return 0;
}
There is a new SourceForge project called SVgUI. The intent is to make a windowing system--Web and possibly desktop-based--using Scalable Vector Graphics (SVG). There are no released files yet, but several promising examples of GUI elements have been posted on the SVG-Developers list.
Sorta off-topic, I know, but you might be interested in working with a community from the ground up.
My word processor was written by Stanford Professor Donald Knuth. Who wrote yours?
I see (at least) 3 distinct levels, and I'm not sure which one your question addresses.
1. Low level graphics manipulation. I would put X here, although X includes network transparency. What I see at this level is graphics primitives. How to draw a circle, a line, a rectangle, draw characters of text in a certian font, etc.
2. A window manager / widget toolkit. There are already five million of these for Linux. They can be fun to write and educational. But don't have any delusions of gaining significant market/mind share.
3. Human-Computer interaction. User Interface. This is more about human psychology than it is about technology. Read some good books like The Design Of Everyday Things. Apple Human Interface Guidelines. (Apple's developer web site.)
Your question makes fairly clear you aren't interested in (1). But it is ambiguous whether you are interested in (2) or (3). If you're interested in (3), then join either the GNOME or KDE projects and contribute ideas and effort that don't involve writing code.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
"For example, menus at the top of the screen (ala MacOS) worked well because a user's motor memory it trained to select items. "
I think that works for small screens as in the original Macs. With big modern screens it's a pain in the arse. I also don't think it works well with the paradigm of over-lapping windows - one needs to associate the menu with active titlebar which could be on the smallest window at the bottom of the screen with a much bigger and more imposing "background" window fully visible in between. If all windows were maximised, this Mac menu paradigm might work, except then it's not much different to having the menu on the window under the titlebar. I also don't think that I'm too keen on the way the Mac menubar mixes application menu items and system items. MSFT do get one thing right with menus: they keep all of the items together at one end, anything else is bad (e.g. Netscape under X with it's Help menu in BFE!)
"Unfortunately, this is broken if the menus change (e.g. MS's idea of hiding items and them bringing them back, moving them around etc.)."
Yes, I agree with you here. MSFT's latest "innovation" of personalised menus is a real pain in the arse. I turned them off immediately - they're so loathesome! Even worse, the user interface for disabling these menus isn't consistent between MSFT apps, and really, if they're going to do it, it should be a display settings property to ensure system-wide consistency.
I mean, who the hell would switch to using an operating system just because the new UI kicks ass?
"And like that
Here is the classic paper on how X could be improved, for example: http://www.std.org/~msm/common/WhyX.pdf.
Write a window manager and fix some GUI toolkit bugs, that's a good way to understand X well. Hack on GUIs like GNOME and KDE to understand where progress is needed on the UI front, and where changing the window system could help.
(I think almost everyone who's actually hacked on this stuff a lot will tell you that replacing X isn't interesting, but if you want to make a credible claim one way or the other, getting experience is the only way.)
go to the plan9 site -l
l
http://www.cs.bell-labs.com/plan9dist/
(for starters see this paper on the old plan9 window system) - http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.htm
there is some information there, and the source code for the window system is actually readable because it is much few lines of code and over all simpler than x windows.
also Rob Pike (who worked on plan9) has written several interesting papers on windowing systems.
try reading them by poking around this site - http://citeseer.nj.nec.com/144447.html
http://citeseer.nj.nec.com/pike89concurrent.htm
(sorry the actual articles - linked off of the above links are only ps or pdf, no html)
These papers, the plan9 window system as well as the inferno window system prove that a simple, elegant window system can be created that is both fast and runs over a network.
Granted these use some features that don't exist in the unix world (like plan9's threading model, and the use of per process namespaces) but I believe these can be emulated somewhat using standard networking.
The size, complexity and performance of x windows are all indications that it is not the optimal solution.
PLEASE PLEASE PLEASE PLEASE PLEASE!!!!!
Don't write any more window managers or windowing systems. When there are window managers out there called "Yet another window manager" or "Yet another window manager2" along with all those window managers that aim to be something special. It's just got to stop. What's needed are better applications that you can be productive with. Please focus on the applications that people demand, not on the ones that you think would be cool to write.
More importantly, this book is just the Windows version of the mostly Unix-centric tomes the poster mentioned he didn't want. A look at the table of contents reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.
There are many possible cost metrics. One puts the most value in the most commonly used cases - if 99% of all users are local, focus on them and drop remote users.
Another valid metric tries to minimize the cost of the legitimate, but rare, users. Network transparency has a small cost, but it's critical for the people who need it.
Yet another valid metric tries to minimize the cost of development. It is extremely cheap to develop X Windows applications in the sense that the API I learned a decade ago is still in use today. Motif has come and gone, and there are now several additional toolkits, but it's nothing like the mishmash that Microsoft has produced in the same period.
(On a similar note, compare how little C has changed between K&R C to ANSI C9X, vs. the massive changes Visual Basic has repeatedly suffered in far less time.)
Yet another metric tries to minimize the cost of developing new drivers. The X wire protocol is well documented, and anyone who develops a driver that speaks it (as either client or server) can be confident that their code can be widely used. Non-wire protocols tend to mutate far more quickly, either decimating the potential user base or driving up development costs.
Put it all together, and the costs of network transparency are outweighed by its many benefits for all but the most demanding local users. And even they gain from it, albeit in more subtle ways.
Is X perfect? Of course not, but many of the "flaws" were actually design goals for long-gone hardware. When was the last time you used a monochrome dumb terminal? The wire protocols need to be extended to reflect the fact that commodity PC prices are now far lower than dumb terminal prices - use the power of those systems! But the key word there is extending the protocols, not replacing them. E.g., make the font system more flexible.
But at the same time, at least once a month I find I need to run an X session remotely, and I can do that from both Unix and Windows boxes. I have never been able to run Windows remotely, although I've heard that BackOrifice is pretty good for that.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The Model View Controller framework abstracts the three separate components of a basic user interface. The Model is the data. This might be a double subscripted array of numbers or a tree of arbitrarily complex nodes. The Controller is probably a keyboard and mouse. There would be some driver code that would deliver mouse and keyboard events to the object currently in focus (or to what ever object registered itself as an event listener). The most important and more sophisticated of these three components is the View.
The View is an area (usually rectangular) of the display device such as a monitor or printer. The key principle behind a view is that it's potentially the child of a parent View. Thus each view may contain subviews each with their own coordinate space. Within a view graphics primiatives and subviews are drawn to create arbitarily complex grapical interfaces. Because the translation to display device coordinates is handled by the graphics context passed to all drawing functions (Graphics g in Java AWT), the implementation of a subview may draw it's widget with respect to coordinates 0,0. This makes it very easy to integrate new custom widgets (widgets stands for "Window Gadgets"). So, for example a frame is a View with a border, a label, and maybe a scrollbar. It has two buttons, some text, and another frame as children. The button is a View that contains a border decor and some text ... etc. This follows the process of Recursive Composition. There is a good description of Views in the BEOS documentation which unfortunately I cannot link to because BE has apprently disabled much of their site. I would appricitate it if someone could point me to a valid link to the description of the BView class.
Ironnically, this framework is repeated in software over and over where only one would really be necessary provided the API were general and flexible. For example, the X-Window system is an MVC framework. But Mozilla has it's own MVC framework for drawing GUI components. Then within Mozilla's rendering engine Gecko is another MVC framework for rendering html components.
In this last case of Gecko, I can understand why they would not want to use a generic windowing MVC API; the layout of components is very strict in that images, links, and the way text flows around components is required to behave in a certain way as to conform to the various associated standards such as CSS and DOM etc. It would be interesting and simplify things tremendously if one could reduce and refactor one unified implementation that parameterized all the different requirements of these MVC frameworks. Then custom components could be potentially integrated into previous unrelated applications (e.g. vi in xterm as the text area of an HTML page).
Check out the Cassoway constraint engine's port to the Squeak system if you are serious about doing new UI/layout libraries: http://penguin.cc.gt.atl.ga.us:8080/schwa/63 For those too lazy to install Squeak and run the above constraint change set for Cassoway under it, here's a little Java 1.1 applet (better run it on Nav4.7x or above) demonstrating how the Cassoway engine maintains dynamic UI consistency within constraints (better read the instructions): http://www.cs.washington.edu/research/constraints/ cda/run.html
Seastead this.
Nope. I'm looking at the screen right now. It's a laptop LCD monitor with exactly 1400x1050, and the image goes all the way to the edge of the display. On a discrete-pixel display like this one, there would be no way to obscure a band of unusable pixels. Further, the X server reports that it's running at a resolution of 1400x1050.
Cut the FUD. I'll grant that there probably was an X server once, somewhere that had to deal with that issue and wasn't able to make an exception for that particular display, but XFree86 4.1 doesn't have that limitation, and it seems very unlikely that any implementation of XFree86 ever did. It never ran on Wyse X terminals.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It's a fascinating approach, that I expect people don't believe could possible work acceptably well.
It's very unfortunate that building a windowing system is so much work that there hasn't been more experimentation with approaches like that with Plan 9...
If you're not part of the solution, you're part of the precipitate.
Also, Lisp is much faster than you think it is. Take a look at this.
I'm sure that device drivers written in Assembler would be faster than device drivers written in Lisp. I don't really care about that. Performance is important, but it isn't the only thing. What I consider to be most important is being able to make the computer do interesting and/or useful things easily.
My only political goal is to see to it that no political party achieves its goals.
Contrary to popular belief, it doesn't force huge gobs of "evil network transparency" in; that pretty much comes for free.
After all, there MUST be an IPC system involved, unless we were to transform it all into some sort of "cooperative multitasking" system with only one process (think: MS Windows, where if any bit of any application breaks, you have to reboot).
As soon as you have IPC, extending that to allow network transparency is pretty easy, and focusing on how "expensive" this is is just silly.
When you start with such huge misconceptions, that undermines the value of the whole discussion.
If you're not part of the solution, you're part of the precipitate.
Just wait for Linux 2.5... Alex Viro had a namespace patch nearly a year ago, and other proposals have come along too...
If you're not part of the solution, you're part of the precipitate.
Unfortunately, this is broken if the menus change (e.g. MS's idea of hiding items and them bringing them back, moving them around etc.).
... ) There was a reason for this. Usability studies reveal that, at most, humans can remember 7 or 8 menu options, no more. So, in their infinite wisdom, MSFT decided to write an app that looks out for which 7 or 8 options a given user actually, well, uses. The other ones get hidden.
NTBAMAB (not to be a microsoft apologist but
It's not a bad idea, the execution is just a bit sucky.
News and bla for computer musicians: http://lomechanik.net/
Display Postscript.. Even Next (or the Next engineers that got absorbed into Apple anyway) realised that was a bad idea. Its a great idea in theory I'll grant you - you get resolution independence, intelligent remote widget representation in a remote terminal environment and relatively easy programming for the app developer.
The problem with it is it's extremely resource intensive (think about it: Postscript is a fully-fledged programming language and you want to put an interpreter for it in your terminal?) plus Adobe patented it and charge a licence fee for its use.
The display engine in Mac OS X is based on the PDF standard instead. You still get the resoltion independence but because PDF is a page description language (declarative) rather than a (functional) programming language you get a less complex and less resource intensive display engine. You lose the intelligent remote widgets but then percentage-wise how many users access GUIs remotely even with a lower-grade solution such as X or (god forbid) VNC compared to those that sit infront of the machine they run all their software on? Very few. Oh, and although Adobe invented PDF, it doesn't charge a licence fee for its use.
It seems to me that a lot of other people have had similar ideas, and the results have all been built on top of X. GTK/Gnome and KDE being two popular examples. I admit that my understanding of what X Windows does is fairly limited, but as far as I know it just a very fast, well written program that draws shapes on your screen and coordinates mouse and keyboard input, all rolled up into a tight, clean client-server interface. I'm not even all that sure if X Windows knows about actual windows; I believe (and this is insightful) that that's handled by the "window manager." So I think when you talk about rewriting the interface, don't you really want to think more about building your own windowing environment on top of X?
I think there is a world market for maybe five personal web logs.
People here seem to forget one thing: There is a framebuffer support in Linux kernel. I know it's still experimental (my experience is that it's quite stable ayway) but..
If you want to do windowing system, want to support a lot of hardware with at least on basic level (VESA) and think it's OK doing it on Linux, try compiling the framebuffer support into your kernel (if it's not there already) and building your system on top of it. There some points why this would be a god idea..
If you make it modular enough (nice wrappers for all framebuffer stuff) it will be easy to port it over to something else or build real hardware drivers later. This way you can first get something running and only then see if you/or somebody can make a better driver for it
Who knows if the project would even speed up framebuffer development if it gets popular enough :)
Software should be free as in speech, but if we also get some free beer, all the better.
i think QTopia is a great idea, if only it ran on desktops
Isen't this what http://savannah.gnu.org/projects/crust/
is all about?
Actually I think this idea is not-so-good(TM).
The biggest advantage of X is that it runs virtually everywhere. I wouldn't give that up by writting something Hurd-specific.
Regards, Tobias
Suggestions such as:
as the user pulls further down the menu, more movement of the mouse is necessary to get a corresponding movement of the pointer
is a perfect example of when not to apply Fittz law. Technically this should be faster, but in reality it blows the users motor memory for how far the mouse should be moved away and results not just in a slower access to that menu, but if used pervasively enough, slow access to everything because the user can no longer guage how far the pointer will move. In short, since moving the pointer is so fundamental to using a GUI, it should be completely consistent to take full advantage of motor memory.
Another indication is:
What they should have done was to curve the keyboard sharply upward, so that merely lifting the finger a few degrees would access the numeric and function keys, aiding both precision and speed.
because it changes how you go about striking a key - you now use an upward action for some keys and downward for others, thus losing motor memory. More than that though, a downward stroke of the fingers is significantly more easily controlled, confident and faster than an outward or upward push. Our fingers handle hitting downward quite sharply, but the ends of our fingers are quite sensitive (or worse still, have finger nails which slip around) so using a downward action moves the point of impact further down from the tips of our fingers (though still up towards the tips so we can hit the keys cleanly) and bending the keyboard up would in fact reduce access time and accuracy.
Finally, at least one person has mentioned that keyboard shortcuts are faster, and this is true in some circumstances. If the shortcut is unintuitive it is not going to be useful. For instance, think about the keyboard shortcuts that save you the most time - I'll bet they're the shortcuts for save (meta-key + s), quit (command-q Mac only really, alt-f4 is a bit too much of a stretch for most people to use cleanly) and probably print (meta-key + p). These are fast because they are so persistant through the user interface that they become intuitive. Alt-F-right-right-down-down is neither intuitive or fast. The time taken thinking about what the key combination is has to be factored into the time required to achieve the goal. Having keyboard shortcuts for everything is not the way to create an effective GUI - have intuitive and easy to remember keyboard shortcuts for the most commonly used tasks however will markedly improve the usability of an application.
It's called "X11". X11 isn't really a "window system", it's a network transparent graphics library. X11 gives you the low-level graphics, access to hardware acceleration, and network transparency. You can build whatever "window system" (in the Windows/Apple sense) on top of that: your own APIs, your own window management, your own input methods, etc.
Display PostScript was an attempt by Adobe to add PostScript to X. It could only draw into a window, you needed to use Xlib to create the window. This was purchased by NeXT and the X part was thrown away and replaced with some simple PostScript calls to create windows to make the NeXT windowing system.
NeWS had an enourmousely simpler and faster method of compressing PostScript into a data stream that pretty much involved reserving some bytes to mean the most common postscript keywords and to introduce arrays of floating point numbers that were imbedded in the data stream. DPS required a compiler that produced machine-specific data structures that also appeared to be highly specific to their PostScript interpreter, I feel this was an infinitely worse design.
NeWS also used PostScript to advantage to control non-drawing things. For instance the shape of a window was controlled by a PostScript path and the position (and rotation!) by a PostScript transformation. Original DPS had none of this, requiring ugly Xlib stuff, and NeXTStep only had simple "create a rectangular window and return it's id" calls that did not integrate so well.
NeWS was enormously better than DPS and anything else out there and it was a shame Sun blew it by trying to charge for it.
I do agree that downloading widgets was NeWS's main defect. It made communication between app and server very difficult and the only programs that really worked were entirely written in PostScript to avoid this communication. But other than this mistake, the unified single interface to create windows, draw *advanced* graphics, and manage events with easy string-based interface was far ahead of anything that has been invented since.
Yes, if I had real Unicode I could have written the "1/2" as a single character like Pike does
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks