X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?
Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn’t get all of those ugly fonts. It’s a trade-off.
I mean clearly the blink tag had to go. It was annoying, unsafe, a blight on the web; not at all like CSS3, JavaScript, WebAssembly and whatever that DRM thing was called, encrypted media extensions, was it? Priorities, man!
Thanks for coming out, the X Windows Chapter was my favorite in the book. :)
Xterm has popup menus, though I don't know when they were added. I've blown people's minds when they saw them. There's also the Tektronix vector terminal emulation in a separate window. It's also trivial to modernize it with features like scroll wheel support because of the flexibility of X resources.
Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network.
And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network.
In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really a bi-directional multiplexed messaging channel, not a pure strict hierarchical relationship, and many client/server dependencies can go both ways over the same connection, at the same time. You can even run an ssh that opens tunnels in both directions, then tunnel X and http connections over that.
Once a connection is established, it really don't matter which end initiated the connection (or how many links and proxies and tunnels there are along the way) -- you're just sending messages both ways.
"Client/Server" is an over-simplified way of describing what's possible.
> Only the server, actually serves the graphics to the user.
The server actually serves the user to the remote client.
It's like "you are not the customer, you are the product". The remote program needs to communicate graphically with you, and connects to the X server to do this; therefore, you are not the requester of a resource, you are the resource being served. :)
Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.
The Nongraphical GUI
XCalc After Several Resizings
https://miro.medium.com/max/434/0*LIDAYbj5NRANRGl7.gif
X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?
Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn’t get all of those ugly fonts. It’s a trade-off.