agumonkey8 years ago
DonHopkins is on HN from time to time, he's always full of things to say about this. Waiting for the wall of history :)
I'm not sure I do. But it does seem like a good question.
Also:
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
Over time they added cooperative multitasking, which meant the foreground app had to consciously give time to let background apps do stuff.
But they could never build a real OS with security and memory protection out of it. So Apple bought NeXT to get industrial strength unix as their core OS, and switched all Apple development to NeXTStep, or at least the modern derivative of it, called Cocoa.
My dust covered Inside Mac volumes were made useless nearly 20 years ago.
Even Multi-Finder was a lot of work because apps happily poked OS globals.
The original Mac OS was more like an embedded app toolkit than an OS. The original implementations were all ROM!
I was working in a group next to the systems software group at Apple when some of the early malware was discovered. After a few days of secrecy, with people being pulled into labs and conference rooms under spooky circumstances, the software managers sent out word that some malware had been found and that people were working on mitigations. They also said something like "Look guys, we know that writing malware is really easy, so don't do it, because we'll fire you immediately if we find out." I distinctly recall that this was in verbal instruction, not a memo, and that the words "really easy" and "really, don't do it" were used.
Naturally my response was to go back to my desk and write a proof of concept. Half an hour and a hundred lines of code later I had something that would replicate a payload whenever you inserted a floppy disk. It was indeed dead easy to do. I exercised my toy for a little while . . . then deleted every trace. I'm sure I wasn't the only engineer who was curious and did this.
So while you couldn't change the ROM, you could definitely muck with the system software, and that's all that really mattered. Zero thought had been given to MacOS security.
- no memory protection.
- system support for patching OS calls.
- no distinction in privileges between application and OS code.
- when mounting any disk, the OS opened a resource file on it
and kept it open. Side effect was that the OS would look for
code fragments defining windows, menus, and controls in that
file. That file normally didn’t contain any, but adding a
malevolent one to that file would mean the OS would run your
code as soon as any program created a standard window, menu
or control.
Obviously they dumped a lot of the OS level APIs for stuff like Control Panels and Desk Accessories, but the standard app APIs were largely unchanged.
There's no fundamental reason they couldn't have made their own OS with the same Carbon APIs that made it into Mac OS X (not that I think they should have—the NeXTStep stuff was much better).
You may know, but for readers who don’t: ”they” didn’t, Andy Hertzfeld did (https://www.folklore.org/StoryView.py?story=Switcher.txt)
It helped that he had intimate knowledge of the Mac operating system’s internals, but many of them were documented in Inside Macintosh, and others could have been found with (quite) a bit of effort; one didn’t have to be at Apple or even have access to the system’s source code to implement that.
And those volumes aren’t useless; they are reminders of about the last time hacking an OS was fun :-;
In the days that your Mac-power-user-penis-length was measured every time you boot by how many extension icons plopped out along the bottom of the screen (and wrapped up to the next line), there was actually a coveted viagra-like meta-penis-extension that you could paste a bunch of ICON's into with ResEdit.
When you booted, it would sequentially plop all those icons out one by one, so it looked like you had as many extensions as you wanted, whatever you wanted them to look like! It would slow down your boot a bit, but it sure was worth it.
It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.
The way X clients can be forwarded over SSH implies that network transparency doesn't need to be built in to the window system, there just needs to be a "seam" at which it can be interposed. Obviously any kind of direct access to graphics hardware makes this impractical.
Plan 9's window system uses the 9p file system protocol to cross the network; another Bell Labs trick (used in Rob Pike's Sam editor) is for the app to be split into two parts with their own internal interface. They can run on different hosts. The internal protocol/interface can be tailored to the app (and can potentially be very simple and/or efficient).
But, yeah, so long as the client is a separate process, getting it transited over the network can be done separately.
(yes, IE & Outlook had UNIX versions: https://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX)
I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.
These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).
So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).
Well worth checking out.
Other than that, it's pretty great.
Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)
Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...
Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites.
All sites can offer any number of different asynchronous message based services to each other at all times.
It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher.
A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s.
In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.
For example, whether you weed dealer "Dave" calls you on the phone and tells you he can drop by if you're interested, or if you call "Dave" and ask him to drop by, "Dave" is still the server, and you're still the client.
1. Heavy Work
2. Interface Logic and Trivial Work
3. Interface Rendering
Some other people want 1 to run on compute servers and 2,3 to run locally.
I really don't think it matters where 2 runs as long as 1 is fast and 3 is responsive.
ssh -X is useful for something like clipboard forwarding from your local desktop to remote server (and back). You can work in something like nvim remotely, and have a nice clipboard integration. What will happen with such functionality after the switch to Wayland?
In theory, a saner approach is using a local editor to edit remote files.
But people don’t do that. Why? Because the available implementations suck. NFS sucks because it’s slow and hangs your programs; sshfs is the same but worse. Vim has native remote file support in the form of scp://, which invokes the scp command every time you open or save a file - synchronously, so even if you’re saving you have to wait. This might be vaguely tolerable if you configure ssh to share connections, but in general it sucks. And with any of those, you have to set up a separate connection to the server and re-find the directory you’re in, which may or may not be time consuming. By contrast, typing vi into the SSH prompt usually just works, so that’s what people do.
But there’s no fundamental technical limitation here. Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side. File transfer would be tunneled through the existing SSH connection, with no setup time or need for re-authentication; it would be fully asynchronous, so the editor would never hard-block waiting for an operation to complete, but it would still indicate when saves have been completed, so you know when it’s safe to run commands on the server that use the new files. Thing is, none of what I just said is especially complex or challenging from a technical perspective; it’s just that it would require changes to a bunch of components (ssh on the client and server; vim) that weren’t designed with that use case in mind.
Anyway, I’m getting a little off topic here - but I think the point generalizes. In my ideal world, the future of X forwarding would be fixing the most common use cases so you don’t need X forwarding. For the rest, well, the ‘server sets up a tunnel over SSH’ approach could work just as well for VNC, or for an improved remote display protocol that uses a video codec.
In the real world, I suppose things will just fester, remote display support will get worse, and remote editing will continue to suck. But I can dream. Or maybe implement something myself, but there are so many other things to do…
And you may find yourself
Behind the wheel of a large Microsoft Mouse
And you may find yourself on a beautiful PC
With a beautiful Window
And you may ask yourself, well
How did I get here?I.e. both methods have their trade-offs. I find using remote nvim easier, even if you have to install and configure it first. At least if we are talking about some stable commonly used environment, and not about ad-hoc editing, in which case remote mounting might be a better option.
Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
>Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side.
Yes, this is possible with emacsclient.
> Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
I’m sure TRAMP is better than vim’s netrw, but at least according to [1] it’s not fully asynchronous. It also seems to require a separate SSH invocation; I know you can configure SSH to reuse physical connections, but at least when I once tried it, it didn’t work very well…
> Yes, this is possible with emacsclient.
Judging by [2], it doesn’t seem to work well for that use case (talking to emacs over an SSH tunnel)… Assuming you can get it to work, can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration? If so, that’s quite interesting and maybe I should check it out. If not, then it still may be quite useful, but it wouldn’t be versatile enough to truly render editor-over-SSH unnecessary.
[1] https://www.reddit.com/r/emacs/comments/23dm4c/is_it_possible_to_make_tramp_not_block_all_of/
[2] https://emacs.stackexchange.com/questions/15144/emacsclient-to-access-remote-emacs-server
>Can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration?
Certainly, of course. Depending on your level of hackery, you can: - Make ssh automatically copy an emacsclient wrapper script over which does the correct thing - Use OpenSSH's Unix socket forwarding on each connection to connect emacsclient to your local Emacs server - Use https://github.com/magit/with-editor
I've never bothered, though, because I run all my shells on remote hosts via TRAMP within Emacs, so when I am in a shell, I can just use open the remote files through the normal Emacs keybindings, rather than typing "emacsclient filename". Thanks to with-editor, this also extends automatically to commands invoked on the remote host which run $EDITOR.
>I don’t have any experience with Emacs, but…
It's not surprising. :) You said "using vi over ssh - or any editor - has always struck me as a hack", "is an unpopular opinion". In fact, it's the consensus in Emacs land. :) Though perhaps that doesn't prevent it from being an unpopular opinion, these days. :)
It has a lot of what you're talking about. Typing `atom foo.conf` to open up files locally. Keeping the same connection open and reconnecting without needing to reauthenticate with SSH.
There's also a lot of other stuff that needs to be handled. File searching needs to be hooked up a reasonable way. Language services do as well.
Facebook has done a great job with remote editing (although I don't think the open source version of Nuclide is a priority).
A split editor, with a local ui and filesystem remote can be made to work, but you do have to install something on the remote end, which brings you back to the remote end doesn't have the environment you want, so you just suffer with whatever is there problem.
It seems when you connect on a remote box many times what you really want is to import its files. But despite there have been a lot of network shared file systems none seams to have become the obvious solution, supposedly because it's hard to fix that problem efficiently in the general case, especially for an operation system, Unix, that attach to files an API that have not been designed for this.
"Mechanism not policy" my ass. X window borders are an archetypal example of the hollowness of that oft-repeated slogan. The slogan should have been "We must strengthen our borders to protect our precious bodily fluids!" ;)
X windows all have a bunch of properties and messages and parameters relating to how to draw window borders in the server.
They have a border width, and a pixel value. They can even have a border pixmap that is tiled with the same origin as the background tile origin (hope that works for you!).
The rationale was that the server could instantly draw window borders and backgrounds before the client refreshed, to give you a bunch of stippled rectangles to look at while you waited for the client to send some drawing commands.
While NeWS's solution was simply for the server to call a PostScript procedure to instantly draw whatever kind of elaborate border plus anything else it wants the user to see (and interact with), without waiting for the client.
Nobody, but NOBODY uses window borders any more. Only the earliest ugliest toolkits like Athena (Anathema) widgets did. It was a terrible idea to build borders into the window system at that level (POLICY!!!), because nobody ever wants to draw borders in a special but extremely limited way built into the window system at a low level, and then draw the rest of the user interface some other way.
X window borders were totally useless for drawing the brutal beveled edges that were fashionable at the time, or even rounded rectangles. Supporting that would be policy! But go to town and express yourself with tiled pixmap borders, that's pure mechanism baby!
https://tronche.com/gui/x/xlib/window/attributes/border.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorder.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorderPixmap.html
Then along came the SHAPE extension.
You'd think it would be straightforward to make an extension that lets you simply set the shape of a window by defining a region somehow.
But no, thanks to borders, each window's shape is defined by TWO regions: the smaller inner client clipping region and the larger outer border bounding region. Well actually it's more than two -- a lot more: There's also their rectangular default core protocol size (both with and without borders), which can be totally different than either of those two other regions's sizes, and modify the effective region.
In summary there are bounding, clip, default bounding, default clip, client bounding, client clip, effective bounding, and effective clip regions. Got it?
Of course all of those regions will almost always be the same since nobody actually uses borders, but thanks to the borders on every window that nobody uses, the SHAPE extension is an order of magnitude more complicated than it needs to be, and even includes a handy glossary and travel guide to all of its various regions.
https://en.wikipedia.org/wiki/Shape_extension
The extension allows defining the shape of two separate regions: the clipping and the bounding regions. These two areas are defined even for windows not using the shape extension: the clipping region is the area that can be used for drawing, the bounding region is the total area covered by the window (that is, the clipping region plus the border). The shape extension allows defining two independent shapes for these two regions.
Both the clipping and bounding are associated, in the shape extension, two areas: a default rectangular region and a possibly non-rectangular client region, defined and changed by the client as specified above. The effective region, which is the actual shape of the window, is the intersection of these two areas. This intersection is performed every time either region is changed: for example, if the client regions contains parts that are outside the default region but the default region is then enlarged, the effective region will include these parts.
https://www.x.org/releases/current/doc/libXext/shapelib.html
Status XShapeQueryExtents(Display display, Window window, Bool bounding_shaped, int x_bounding, int y_bounding, unsigned int w_bounding, unsigned int h_bounding, Bool clip_shaped, int x_clip, int y_clip, unsigned int w_clip, unsigned int *h_clip);
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is nonempty, the border is filled using the border-tile or border-pixel of the window as specified in the core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, since the clip shape can still be made smaller than the bounding shape.
Glossary
bounding region: The area of the parent window that this window will occupy. This area is divided into two parts: the border and the interior.
clip region: The interior of the window, as a subset of the bounding region. This region describes the area that will be painted with the window background when the window is cleared, will contain all graphics output to the window, and will clip any subwindows.
default bounding region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and its border.
default clip region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and excludes the border.
client bounding region: The region associated with a window that is directly modified via this extension when specified by ShapeBounding This region is used in conjunction with the default bounding region to produce the effective bounding region.
client clip region: The region associated with a window that is directly modified via this extension when specified by ShapeClip This region is used in conjunction with the default clip region and the client bounding region to produce the effective clip region.
effective bounding region: The actual shape of the window on the screen, including border and interior (but excluding the effects of overlapping windows). When a window has a client bounding region, the effective bounding region is the intersection of the default bounding region and the client bounding region. Otherwise, the effective bounding region is the same as the default bounding region.
effective clip region: The actual shape of the interior of the window on the screen (excluding the effects of overlapping windows). When a window has a client clip region or a client bounding region, the effective clip region is the intersection of the default clip region, the client clip region (if any) and the client bounding region (if any). Otherwise, the effective clip region is the same as the default clip region.
Rightly or wrongly, modern GUIs tend to be sufficiently graphical that X turns into effectively sending bitmaps anyway, so in my experience a lightly compressed VNC is more responsive.
It is nice that in X individual windows can live independently, but adding that to your windowing manager feels like less work, and is how for example windows works nowadays (don't know other windowing systems well enough).
You can do that on various Linux distros with xpra [1].
In X11 it is just as expensive to change the foreground color as to draw one dot (since all the overhead is sending the command), but you could efficiently draw a lot of dots of the same color with XDrawPoints, so it was worth it to sort the pixels by color and then draw them in a few same-colored batches, instead of switching colors between each pixel you draw.
I disabled that crazy code for the OLPC port since it was always running locally and XPutImage would always always use the shared memory extension, but in the days when you wanted to run remotely over a slow network, or the local server didn't support the shared memory extension, it was well worth doing all the work of comparing and sorting individual pixels to incrementally update the map!
https://github.com/SimHacker/micropolis/blob/master/micropolis-activity/src/sim/w_map.c#L466
(I'm sure that code used to work on old 8 bit displays, but for some reason I never bothered to figure out, it was buggy on the OLPC's 24 bit visual, so I #if'ed it out of its misery. That's X11 for you.)
https://github.com/SimHacker/micropolis/blob/master/micropolis-activity/src/sim/w_map.c#L543
Don't worry, in time everything will be re-invented on the web. With WebGL, the browser becomes just like an X server, only with a far richer feature set for malware authors.
People just don't seem to get this. If I can't alt-tab between windows, remote GUI apps are next to useless for me. It breaks my workflow. I hit this speebump all the time when working with VMs and RDP.
I discovered the great work of Morgan Dixon and James Fogarty, which proves that you can do some amazing things with screen scraping, pattern matching, visual deconstruction, augmentation and reconstruction! His work needs to be combined with platform specific accessibility APIs via JavaScript.
I'm proposing "aQuery", a high level scriptable accessibility tool that is to native user interface components like jQuery is to DOM, for selecting and querying components, matching visual patterns, handing events, abstracting platform dependencies and high level service interfaces, building and scripting higher level widgets and applications, etc.
http://donhopkins.com/mediawiki/index.php/AQuery
https://news.ycombinator.com/item?id=11520967
Morgan Dixon's and James Fogarty's work is truly breathtaking and eye opening, and I would love for that to be a core part of a scriptable hybrid Screen Scraping / Accessibility API approach.
Screen scraping techniques are very powerful, but have limitations. Accessibility APIs are very powerful, but have different limitations. But using both approaches together, screencasting and re-composing visual elements, and tightly integrating it with JavaScript, enables a much wider and interesting range of possibilities.
Think of it like augmented reality for virtualizing desktop user interfaces. The beauty of Morgan's Prefab is how it works across different platforms and web browsers, over virtual desktops, and how it can control, sample, measure, modify, augment and recompose guis of existing unmodified applications, even dynamic language translation, so they're much more accessible and easier to use!
https://news.ycombinator.com/item?id=12425668
This link has the most up-to-date links to Morgan's work, and his demo videos!
https://news.ycombinator.com/item?id=14182061
Prefab: The Pixel-Based Reverse Engineering Toolkit Prefab is a system for reverse engineering the interface structure of graphical interfaces from their pixels. In other words, Prefab looks at the pixels of an existing interface and returns a tree structure, like a web-page's Document Object Model, that you can then use to modify the original interface in some way. Prefab works from example images of widgets; it decomposes those widgets into small parts, and exactly matches those parts in screenshots of an interface. Prefab does this many times per second to help you modify interfaces in real time. Imagine if you could modify any graphical interface? With Prefab, you can explore this question!
https://www.youtube.com/watch?v=w4S5ZtnaUKE
Imagine if every interface was open source. Any of us could modify the software we use every day. Unfortunately, we don't have the source.
Prefab realizes this vision using only the pixels of everyday interfaces. This video shows how we advanced the capabilities of Prefab to understand interface content and hierarchy. We use Prefab to add new functionality to Microsoft Word, Skype, and Google Chrome. These demonstrations show how Prefab can be used to translate the language of interfaces, add tutorials to interfaces, and add or remove content from interfaces solely from their pixels. Prefab represents a new approach to deploying HCI research in everyday software, and is also the first step toward a future where anybody can modify any interface.
More Prefab demos:
There needs to be a higher level scriptable way to get a handle on all that complexity, like jQuery helps automate the creation and manipulation and abstraction of HTML DOM and events and handlers.
PhoneGap/Cordova plugins and NativeScript both take a similar approach: they have a generic Objective C / Java / Whatever <=> JavaScript bridge that lets you directly call all (or most) of the native APIs, including accessibility, directly on each platform. Then you write higher level platform independent APIs on top of the native APIs in JavaScript, a different one for each platform, but the same high level interface to JavaScript programmers.
https://docs.nativescript.org/core-concepts/accessing-native-apis-with-javascript
I would try to use the native API as much as possible since they're precise yet tedious. It should have a platform-independent accessibility-specific selector language like xpath or jQuery selectors, which should be implemented efficiently in native code like querySelector. The pattern matching engine would send asynchronous events back to JavaScript. You could write JavaScript handlers for patterns of pixels as well as accessibility path patterns appearing and disappearing, like jQuery lets you bind handlers to patterns of DOM elements that don't exist yet, instead of concrete existing elements. Those handlers would create higher level widgets that could manage those existing pixels and widgets. (Like recognizing a youtube video player in any web browser window, and wrapping it in an aQuery widget implementing an abstract VideoPlayer interface, for example.)
Of course calling the native accessibility API is lighter weight than screen scraping and pixel matching, and you could use the native API to drill down to just the region of pixels you want to match or screencast, to minimize the amount of screen scraping and pixel matching required.
Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
At the end it is sad that he was proud of being right even though he was an _hole (his word). It could have been that he was right and his best ideas were in common use.
Working hard to build great stuff and arguing/fighting for what is right can be forceful without being debasing, divisive, or insulting.
There are those of us who see collaboration as orthogonal to innovation and thus don't put any effort into it. Fortunately, there's a good mix of talent and dispositions out there to make up for it.
> Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
Imagine a world where everyone is the same and has the same set of values. That may seem like paradise to some, but it sounds like doom to me.
> At the end it is sad that he was proud of being right
He was proud that he didn't compromise, even though that would've been easier, and no one would've faulted him for it.
On the other hand, all of the input, graphics and "other crap" being mandatory means that as a developer you can pretty much guarantee that they are there and if you care about having your stuff work everywhere (well, everywhere X is available anyway) you can simply rely on that without having to support a bunch of different APIs that may or may not be there (see the audio situation a few years ago in Linux).
(also FWIW a lot of people use the X primitives, not everyone uses Gtk or Qt)
Where it fell down was all the complication about XVisuals and colours etc. Those things were solving real problems for the era but doing so with an unnecessarily complicated interface that tied the 2d-primitives and much else into the assumptions of that era.
Thus as things developed, whole new APIs like XRender had to be invented in order to do the dumb basic primitives again.
But I totally agree with you about colors (the X approach to device independence is to treat everything like a MicroVAX framebuffer on acid), and xRender (which was wonderful work that transcended X11 and led to Cairo and html's canvas).
And don't get me started about window borders, and the SHAPES extension, and their fractally complex interactions!
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
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.
Probably we are agreeing past each-other. I meant they were OK in a very board sense that you want primitives for drawing lines, drawing polygons, filling things, blitting things etc. I think you agree with me about that.
And I also think we both agree that the details of those primitives in X11 were a disaster.
The flip side is that you have to worry about weird aliasing (or anti-aliasing!) artifacts, such as black lines turning grey.
Basically, name me an app that uses solely X11 primitives without the use of any extensions and no overlying library over libX11 (and no, xclock doesn't count)
For example my own Little Forms library [0] uses the X server's drawing and text operations (you can use Xft instead, it is a build option, but you can also make a static library for binaries that rely only on xlib and nothing else).
Sometimes he's even out driving a tractor in his field! ;)
NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.
X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life.
But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non-rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).
Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it's extensible and customizable and drawn in PostScript.
Here's a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.
https://www.youtube.com/watch?v=tMcmQk-q0k4
Here are some flames and notes I wrote years ago about X11 and NeWS window management -- the "OWM" section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.
http://www.donhopkins.com/home/catalog/unix-haters/x-windows/i39l.html
Basically, we didn't want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.
http://www.donhopkins.com/home/catalog/images/pizzatool.gif
Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out "ClassX11ManagerMixin", which is what it sounds like. It's mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:
http://www.donhopkins.com/home/archive/NeWS/owm.ps.txt
It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task-oriented interfaces by composing widgets and apps into "cards", "backgrounds", "stacks" and optional network "clients". But that's not how things turned out. ;/
http://www.donhopkins.com/home/catalog/hyperlook/index.html
http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1.gif
http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas4.gif
http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfacing.gif
http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime.gif
I'll excerpt the relevant parts of the i39l flames:
Who Should Manage the Windows, X11 or NeWS?
This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.
Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.
Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!
Some notes about OWM
OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!
This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!
X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.
I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.
If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?
Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity.
NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way.
NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays.
Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback.
Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor.
NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc).
SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent).
If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS).
"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/overview.htm
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
My favorite chapters:
"A Comparison of Some Window Managers" by Tony Williams: http://www.chilton-computing.org.uk/inf/literature/books/wm/p003.htm
"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/p004.htm
"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/p017.htm
"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/p018.htm
Here is some of the ui working group discussion specifically about tiling windows:
17.2 INTERFACE TECHNIQUES
Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.
Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.
Even with NeWS 1.1, you were still running parts of SunView underneath.
One cool thing that X11/NeWS could do was that X11 clients could transparently use scalable PostScript fonts, including the nice hinted "Folio" fonts, and even "user defined fonts" written in PostScript like the Hershey and Dijkstra fonts. The X11 server could call back into the NeWS PostScript interpreter to render the font at any point size!
People cursed with diskless Sun 3/50's would run xterms and emacs's across the net on each other's workstations instead of locally. It was noticeably less sluggish, because you didn't get hit with all the heavyweight process context switching between X clients and server every keystroke.
To that end, one of the weirder and cooler re-implementations of NeWS was Cogent's PIX for transputers. It was basically a NeWS-like multiprocessing PostScript interpreter for Transputers, with Linda "tuple spaces" as an interprocess communication primitive:
http://ieeexplore.ieee.org/document/301904/
The Cogent Research XTM is a desktop parallel computer based on the INMOS T800 transputer. Designed to expand from two to several hundred processors, the XTM provides a transparent distributed computing environment both within a single workstation and among a collection of workstations. Using Linda tuple spaces as the basis for interprocess communication and synchronization, a Unix-compatible, server-based OS was constructed. A graphic user interface is provided by an interactive PostScript window server called PIX. All processors see the same set of system services, and within protection limits, programs capable of using many processors can spread out over a network of workstations and resource servers, acquiring the services of unused processors.
But toward the end, he says that the particular kind of technical train-wreck that they got was similar to the Mac API (presumably the this means the pre-OS X OS). "[As a resulting of accidentally being lots of databases] the X API is wide and shallow like the Mac, and full of interesting race conditions to boot."
Anyway, I didn't think that design by committee was one of Apples weaknesses.
It fascinates me that something so widely regarded as Bad and Wrong, proved so hard to replace when it’s baked into a system. I think there’s a cautionary tale about the necessity of getting your core APIs right, because you might never be able to get rid of them.
IBM for example did most of their RISC research with an OS written in PL/8, where they prototyped many ideas about modular compilers, a few of them visible in how LLVM works.
Then by being a plain CLI based OS versus what was being done at Xerox PARC with Xerox Star and Pilot (done in Mesa).
NeXTSTep was probably the only variant that got close of the Mac, Amiga and Atari multimedia capabilities, and even it wasn't a pure UNIX, rather used it as a means to bring applications into the NeXT world.
Many mainframe ideas about OS security are still not part of any UNIX clone, as another example.