How X Window Managers Work, and How to Write One (2014) (opens in new tab)

(jichu4n.com)

276 pointsfirefly2844y ago244 comments

244 comments

61 comments · 13 top-level

fyrn-4y ago· 23 in thread

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

1. The article was written in 2014.

2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.

mrweasel4y ago

Someone has started work on OpenBSD Wayland: https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-...

I doubt it's something that will be ready for 7.1 next spring, but it's nice to see that it's actually working.

pimeys4y ago

I've been using Wayland and Sway with FreeBSD 13 quite successfully. Everything worked quite well, except some indicators in Waybar that were using some Linux specific things to get values for memory usage etc...

mcguire4y ago

3. Wayland has been "starting to take off" for longer than many of the readers here have been alive.

loxias4y ago

> replacemeant for Xorg

WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.

There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.

perth4y ago

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland.

Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work

Some relevant links for those curious about other people hitting into this:

https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi...

Gnome team:

https://wiki.gnome.org/Initiatives/Wayland/XWayland

3 more replies

ch_1234y ago

Here is one list of problems with X11 which Wayland solves. One of the author is someone who has done a lot of work on Xorg, so they know what they are talking about: https://www.phoronix.com/scan.php?page=article&item=x_waylan...

2 more replies

II2II4y ago

I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me.

As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.

1 more reply

blacklion4y ago

Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time. It is better than both X11 and plain framebuffer in this role, for sure.

2 more replies

Seirdy4y ago

The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago.

Advanced mixed DPI also comes to mind.

Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.

2 more replies

RedShift14y ago

> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.

This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.

1 more reply

Hendrikto4y ago

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.

Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.

Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

2 more replies

josefx4y ago

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

5e92cb50239222b4y ago

What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years.

From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.

4 more replies

qwerty4561274y ago

This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine and that was very easy).

Seirdy4y ago

1. Wayland does support remote execution; see waypipe for an example.

2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

2 more replies

upofadown4y ago

It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.

kaba04y ago

Wlroots would like a word with you.

1 more reply

zephyr94y ago

Does upstream Wayland work on any platform except for Linux?

Does this display server have any form of colour management for, you know, the stuff it's displaying?

Wayland is taking off like the Spruce Moose...

emersion4y ago

Feel free to continue using X11 of course, no one's forcing anybody to switch. That said:

> Does upstream Wayland work on any platform except for Linux?

Yes, FreeBSD. Patches welcome to make it work on other BSDs.

> Does this display server have any form of colour management for, you know, the stuff it's displaying?

No more than X11 right now, ie. none. But it's in the works.

1 more reply

sprash4y ago

> right as the replacemeant for Xorg starts to take off though

It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.

Seirdy4y ago

Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years.

On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar.

Wayland has already taken off; once we get XFCE to switch we should be able to move on.

3 more replies

DonHopkins4y ago

FWIW, that's much less time than Perl 6 has been taking off for!

cunidev4y ago· 6 in thread

Is there anything similar for Wayland? Its protocol looks considerably more complex than Xorg's, and so are most resources to learn it.

samus4y ago

It's quite ardous and unfun, but the wlroots project does most of the heavy lifting. For beginners it's probably useful to create a toy WM using wlroots[0] and dig deeper from there[1].

[0]: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master... [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getti...

ashkankiani4y ago

sway and wlroots have some of the worst error handling I've ever seen in C code. The number of null pointer bugs and assertion bugs is just mind-boggling. I don't really understand how hard it is to just gracefully handle errors. Literally no one would prefer to crash their entire desktop environment rather than have it silently skip over errors and output them to a log.

I recently used i3 again because my office computer has an NVIDIA GPU and sway doesn't support NVIDIA (yes I'm aware of the new GBM API, it's not ready yet and I don't care anymore anyway). It made me realize how much more gracefully i3 handles a lot of things, and also a few things it really doesn't (but that's more the fault of X11, not i3).

It's disappointing that the defacto library for Wayland is wlroots given those bugs.

1 more reply

wing-_-nuts4y ago

The last time I used wlroots, via sway, I encountered a bug where I experienced 'multicolored snow' when watching a video in firefox. I wanted to record a video of it to report a bug, but of course that wasn't possible because screen sharing / recording still isn't well supported. Back to gnome I went, and I still don't think wayland is ready for primetime on smaller window managers

1 more reply

ximm4y ago

I think the dwl codebase is an excellent read: https://github.com/djpohly/dwl

phendrenad24y ago

Most of the concepts here are the same for wayland. The only difference is, Wayland handles compositing, whereas in x11 compositing is a pluggable component.

yissp4y ago

A Wayland compositor is responsible for quite a bit more than an X11 window manager. Compositing, as you mentioned, but also display modesetting, input handling, clipboard management, and so on. Although, of course, one can use a library like wlroots or libweston to handle most of that stuff if you just want to focus on the desktop experience.

DonHopkins4y ago· 4 in thread

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>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 must 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

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend):

https://blog.dshr.org/2018/05/recreational-bugs.html

>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

mcguire4y ago

"[Footnote: We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the application is running,” and when you see “Server” think “the local machine that displays output and accepts user input.”]"

Still having problems with the difference between a client and a server, eh?

P.s. I'm starting to view this article the same way Tesla did the Top Gear review episode: it was cute the first time, but...

DonHopkins4y ago

I don't get what you point is. What problem or confusion do you think I have with the difference between the terms "client" and "server", and are you blaming me that a remote X-Windows client is called a "client" and a remote web server is called a "server"? Or is it my fault that web "servers" and web browser "clients" are called the other way around than X-Windows "clients" and X-Windows "servers"? Or are you just offended that I pointed out that fact?

The fact that the web finally ended up the way it did, with a so-called "AJAXian" architecture using JavaScript in the web browser (and often the web server too) (not to mention the PostScript Stencil/Paint imaging model in canvas), instead of a fixed protocol like X-Windows (stuck with its terrible obsolete imaging model), certainly proves my point that NeWS's architecture of sending code instead of a fixed protocol like X-Windows is by far the superior, more efficient, future-proof, open-ended architecture.

The term "AJAX" was coined in 1999, but NeWS (aka SunDew) was doing it in 1985, 14 years before the term "AJAX" was coined in 1999. And X-Windows still isn't doing it, 37 years after James Gosling originally proposed that architecture in his paper describing SunDew.

https://en.wikipedia.org/wiki/NeWS

>NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

>used PostScript code instead of JavaScript for programming.

>used PostScript graphics instead of DHTML and CSS for rendering.

>used PostScript data instead of XML and JSON for data representation.

I worked on the display driver for the NeWS version of Gosling/UniPress Emacs, and also on the NeWS display driver for Gnu Emacs, and thanks to NeWS's ability to download code that implements application specific protocols, both versions of Emacs ran quite smoothly, efficiently, and responsively over slow dial-up modems, ISDN, and the slow internet connections of the late 80's - early 90's.

Here's an email I sent to James Gosling in 1988 describing how the Emacs display driver I implemented for UniPress Emacs 2.20 works, by providing smooth live text selection feedback without requiring client/server round trips every time the mouse moves, as well as interactive pie menus and tabbed windows, all implemented in PostScript in the NeWS server:

https://www.donhopkins.com/home/archive/emacs/to.jag.txt

>Hi! I'm working on Emacs this summer at Unipress. It now supports menus, and text selection, with rubber banding in the server. It works, and is much fun to use, but I have a few questions about getting it RIGHT!

>When you initiate a selection by clicking with the mouse, emacs replies with an array of the line widths in the current window, and the row of the window's top line. Some code I stole from nterm rubber bands an outline around the text as you drag around the window. I modified it to show that a line's trailing newlines was selected by drawing the right edge with an arc or a slant.

>[...] Other stuff we're working on include a menu compiler, which compiles nested menus described as linked info nodes into PostScript code and MLisp key bindings. (Menu keys are assigned keystroke sequences, with keytop names that identify them, which are bound to MLisp functions. Menu keys can invoke submenus or do anything else you want, too.) So you can make menus without touching PS or MLisp! The menus all run in the server, so you can type into the emacs underneath while you're in the middle of completing a menu selection. I changed getmenuaction to execute executable keywords, to support indirect submenu references, and magic functions that decide the submenu or menu action.

>[...] I made a class of window that has thin borders, and a little handle sticking out the top right with its FrameLabel -- you can have a bunch of them overlapping, and their names all stick out to the right, where you can click on them to bring them to the top or get a frame menu. They work really well with multiple emacs frames!

>Thanks for all the neat toys!

Here's a screen snapshot of that code running, from the wikipedia page about tabbed windows:

https://en.wikipedia.org/wiki/Tab_(interface)#/media/File:Hy...

And here's the PostScript source code of the emacs client side display driver:

https://www.donhopkins.com/home/archive/emacs/emacs.ps

Also, in case you weren't aware, a single X-Windows "client" can have simultaneous connections to multiple X-Windows "servers", in the same way that a single web "server" can have simultaneous connections to multiple web "browsers".

A good example is SimCity (aka multi player SimCityNet and open source Micropolis), which is a commercial product that I developed for NeWS in PostScript, for X-Windows in TCL/TK (later releasing a single player version as Micropolis for the OLPC), and a multi player open source version for web servers in Python (whose distributed client/server "AJAXian" architecture was most similar to the original NeWS version, no matter how you label the client and server).

The TCL/Tk/X11 version of multi player "SimCityNet" supported simultaneous connections to several players on different (or the same) X-Windows servers at once, so they could play together in the same city.

Product Announcement: Multi Player SimCity for X11 is now available from DUX Software! (1993):

https://www.donhopkins.com/home/catalog/simcity/simcity-anno...

SimCityNet: a Cooperative Multi User City Simulation (1993 INTERCHI Amsterdam demo)

https://www.donhopkins.com/home/catalog/simcity/simcitynet.h...

Multi Player SimCityNet for X11 on Linux. Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins:

https://www.youtube.com/watch?v=_fVl4dGwUrA

Micropolis Online (multi player SimCity running on a web server in Python) web demo. A demo of the open source Micropolis Online game (based on the original SimCity Classic source code from Maxis), running on a web server, written in C++ and Python, and displaying in a web browser, written in OpenLaszlo and JavaScript, running in the Flash player. Developed by Don Hopkins.

https://www.youtube.com/watch?v=8snnqQSI0GE

Unfortunately the support for multi-player applications in X-Windows toolkits like TCL/Tk was buggy and incomplete, so I had to fix it for SimCityNet, and the support for security and authentication in X-Windows is STILL abysmally terrible, so I had to drop the multi player feature from the OLPC version of Micropolis, because I wouldn't want to require children to type "xhost +" or enter hexadecimal magic cookies and ip addresses to play a game.

But it was much safer and easier to implement a secure multi player game in Python on a web server over https to multiple simultaneous web browsers.

Here's the Python source code of the web server, which uses the C++ reimplementation of SimCity called MicropolisCore via SWIG wrappers:

https://github.com/SimHacker/micropolis/blob/master/turbogea...

And to demonstrate what I mean by downloading procedural code implementing custom compression protocols between client and server instead of using a fixed protocol, and communicating using efficient application specific protocols instead of rigid fixed protocols like X-Windows, here is a concrete example you can see for yourself.

This is the server side of the tile compression protocol: GetTileData returns a buffer of compressed tile differences (of only the tiles the user can currently see) to send to the browser, which is further optimized to support SimCity's notion of "animated tiles", so it doesn't even have to send deltas for tiles that are automatically animate in the client, or outside of the user's scrolling view:

https://github.com/SimHacker/micropolis/blob/master/Micropol...

The Python code running in the web server gets the compressed tile data and sends it to the client:

https://github.com/SimHacker/micropolis/blob/master/Micropol...

The JavaScript code running in the web browser receives the compressed tiles, decompresses them, and updates the tile view:

https://github.com/SimHacker/micropolis/blob/master/laszlo/m...

The resulting distributed real time animated user interface is quite snappy and responsive over the network (especially the pie menu, which track input, interact, and display feedback locally, and only send messages to the server upon completion), as you can see in the demo video above.

Are you following along so far? This "AJAXian" architecture is precisely what James Gosling was writing about 36 years ago in 1985, when he described the client interaction of "SunDew", which was later renamed "NeWS":

http://www.chilton-computing.org.uk/inf/literature/books/wm/...

>5.3.4 Client Interaction

>Client interaction with the window system can be broken down into three layers: messages that get passed between the window system and the client, the programs that are contained in the messages, and a procedural interface to program construction. This is one of the key unique points about this window system: clients send programs to the window system whose elaboration causes graphic operations to appear. The client program does not send graphic operations directly. There is, of course, a procedural interface to program construction that blurs the distinction.

>This approach allows the client to redefine the protocol to compress messages passed to the window system. For example, if the client wishes to draw a grid it can download a procedure which iteratively draws the lines, generating their coordinates as a function of the loop index. This is a substantial compression over transmitting a large set of lines, even if the grid is drawn only once. There are other performance advantages: message-passing interactions are relatively slow and downloading a procedure that will respond locally eliminates this overhead. For example, if a client program needs rubber band lines, then rather than have the window system send a message to it each time the mouse moves, it can download a procedure that will track the mouse locally.

>There are a number of features of PostScript that make it attractive. It is very simple, and it is complete. Its simplicity makes it fast to translate and interpret - this can almost be done as quickly as packets can be disassembled in a more traditional IPC environment. Adobe did a very good job of designing a set of primitives and data structures that fit together well. Its chief drawback is that it can be hard for people to understand; the postfix notation is well-suited to consumption and generation by programs, but humans find it obscure.

>It is important to think about the client programmer's model of what the window system does. We expect there to be two levels of model. The first completely hides the existence of PostScript with a veneer of procedure calls that construct and transmit fragments of PostScript programs. The second exposes PostScript. Beyond a certain level of functionality, learning PostScript is inevitable: it can be pushed off by making the veneer more comprehensive, but this just makes the eventual leap harder.

1 more reply

marcodiego4y ago

Hi DonHopkins!

Would you mind to share your opinion on Wayland with us?

DonHopkins4y ago

Thanks for asking! Hold my bong. ;)

I've never had any reason to use Wayland or desire to learn much about it, so I can't tell you anything technical or from first hand experience.

But I think we have X-Windows to thank for the fact that most Unix programmers use Macs now.

And it's way too late for Wayland to change that fact. Especially with the release of the M1 Max. That ship has sailed.

It didn't matter how much better NeWS was than X-Windows -- it still lost despite all its merits.

And I don't see Wayland as being any more better than X-Windows, than NeWS was better, decades ago.

So simply "being better than X" is not sufficient to displace it, and Wayland isn't even that much better than X, and is even worse in some ways.

The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start, and its designers should have considered the design and architecture of NeWS and Emacs and Blender and Redis and web browsers before designing Yet-Another-X-Windows-Clone. It's not like those ideas were secret, or patented, or hard to find, or wrong.

The world moved up the stack a layer to the web browser, and that's where all the excitement's happening these days, not in the window system layer.

Why have X-Windows or Wayland at all, when you could just run the web browser itself directly on the hardware, as efficiently and flexibly as possible, and implement all your user interface, window management and desktop stuff with modern open standard JavaScript / WebAssembly / JSON / XML / HTML / SVG / CSS / Canvas / WebGL / WebGPU / HTTPS / WebRTC?

I've written about this numerous times before, but I'll transclude and reorganize some of it with checked and updated archive urls to save you the pointing and clicking:

https://news.ycombinator.com/item?id=5844345

>colanderman>And this is my primary issue with Wayland. I cannot fathom why anyone would think it's a sound design decision to bundle a hardware-independent component (the window manager) with a hardware-dependent component (the compositor). This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck BSD uses, etc.

>Just put a JavaScript (or whatever) interpreter in the window server, and program the window manager locally in that. Then you aren't fucked by synchronization issues. James Gosling did something like that with PostScript many years ago, an alternative to X11, which was then merged with X11, and it was called NeWS (and later X11/NeWS or OpenWindows):

http://en.wikipedia.org/wiki/NeWS

>I've written several window managers / user interface toolkits / tabbed window frames / menu system in PostScript for NeWS. We even wrote an X11 window manager in PostScript, complete with rooms, scrolling virtual desktop, tabbed windows, pie menus, and seamless integration of X11 and NeWS windows.

https://www.youtube.com/watch?v=tMcmQk-q0k4

https://news.ycombinator.com/item?id=5845119

>Having the window manager running as an outboard process, communicating via an asynchronous protocol, is a terrible idea, but is baked into X11 at a very low level -- with the ICCCM thrown in as a kludgy afterthought. The X11 protocol has hacks and band-aids like "mouse button grabs" and "server grabs" to mitigate the problems, but they cause a lot of other problems, complexity and inefficiencies on their own.

https://news.ycombinator.com/item?id=20182294

>That's exactly the point of using HyperLook as a window manager, which we were discussing at Sun in 1991 before they canceled NeWS.

>HyperLook, which was inspired by HyperCard, but written in PostScript for the NeWS window system, let you build specialized task-oriented user interface by assembling and customizing and scripting together components and applets into their own "stacks".

https://news.ycombinator.com/item?id=19007885

>HyperLook (which ran on NeWS, and was like a networked version of Hypercard based on PostScript) was kind of like looking outwards through windows, in the way Rob Pike described the Blit (although it was architecturally quite different).

>I think his point was that window frames should be like dynamically typed polymorphic collections possibly containing multiple differently typed components that can change over time (like JavaScript arrays), not statically typed single-element containers that are permanently bound to the same component type which can't ever change (like C variables).

>With X11, the client comes first, and the window manager simply slaps a generic window frame around it, subject to some pre-defined client-specified customizations like ICCCM properties to control the window dressing, but not much more, and not under the control of the user.

>With HyperLook, the "stack/background/card" or window frame came first, and you (the user at runtime, not just the developer at design time) could compose any other components and applications together in your own stacks, by copying and pasting them out of other stacks or warehouses of pre-configured components.

https://donhopkins.medium.com/hyperlook-nee-hypernews-nee-go...

>For example, I implemented SimCity for HyperLook as a client that ran in a separate process than the window server, and sent messages over the local network and drew into shared memory bitmaps. SimCity had its own custom frames ("screw-up windows") that looked more "mayoral" than normal windows.

https://cdn-images-1.medium.com/max/2560/0*ZM8s95LNxemc5Enz....

>There were multiple map and editor views that you could copy and paste into other stacks while they were running, or you could copy widgets like buttons or drawing editors into the SimCity stack while it was running. So you could copy and paste the "RCI" gauge into your graphics editor window to keep an eye on it while you worked, or paste a clock into your SimCity window to see when it was time to stop playing and get some sleep. And you could even hit the "props" key on the clock to bring up a PostScript graphics editor that let you totally customize how it looked!

https://cdn-images-1.medium.com/max/600/0*oHtC0F5qK83ADw1H.g...

>It had "warehouse" stacks containing collections of pre-configured component prototypes (including widgets, applets, and window management controls like close buttons, resize corners, navigation buttons, clocks, graphics editors, etc) that you could copy and paste into your own stacks, and which would automatically be listed in the "New Object" menu you get in edit mode, to create them in place without opening up the warehouse:

https://cdn-images-1.medium.com/max/600/0*sHClGU8ALljuRQKb.g...

https://cdn-images-1.medium.com/max/600/0*QwIQ_GLxQl1v968F.g...

https://cdn-images-1.medium.com/max/600/0*aWbuo6k_eJuZnUmV.g...

https://cdn-images-1.medium.com/max/600/0*zya4vNBP3libpNSA.g...

https://cdn-images-1.medium.com/max/600/1*G0LWky2iejYm4IGBsU...

>Normal X11 window managers put the cart before the donkey. The window frames are generic, stupid and unscriptable, and can't even be customized by the user, or saved and restored later. The client comes first, with just one client per generic frame. You can't move or copy a widget or panel from one frame to another, to use them together in the same window. That's terribly limited and primitive.

>We implemented a more-or-less traditional (but better than normal) ICCCM X11 window manager in PostScript for X11/NeWS, which had tabbed windows, pie menus, rooms, scrolling virtual desktop, etc, uniformly for all NeWS apps and X11 clients. But the next step (not NeXT Step) was to use HyperLook to break out of the limited one-client-per-frame paradigm.

http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...

>(It's interesting to note that David Rosenthal, the author of the ICCCM specification, was also one of the architects of NeWS, along with James Gosling.)

>Our plan was to use HyperLook to implement a totally different kind of integrated scriptable X11 (and NeWS) window manager, so you could compose multiple X11 clients into the same frame along with HyperLook widgets and scripts. You could integrate multiple X11 clients and NeWS components into fully customizable seamless task oriented user interfaces, instead of switching between windows and copying and pasting between a bunch of separate monolithic clients that don't know about each other. But unfortunately Sun canceled NeWS before we could do that.

>Here's some more stuff I've written about that stuff, and how window managers should be implemented today in JavaScript:

https://news.ycombinator.com/item?id=18837730

>That's how I implemented tabbed windows in 1988 for the NeWS window system and UniPress Emacs (aka Gosling Emacs aka Evil Software Hoarder Emacs), which supported multiple windows on NeWS and X11 long before Gnu Emacs did. That seemed to me like the most obvious way to do it at the time, since tabs along the top of bottom edges were extremely wasteful of screen space. (That was on a big hires Sun workstation screen, not a tiny little lores Mac display, so you could open a lot more windows, especially with Emacs.)

>It makes them more like a vertical linear menu of opened windows, so you can real all their titles, fit many of them on the screen at once, and you instantly access any one and can pop up pie menus on the tabs to perform window management commands even if the windows themselves are not visible.

https://news.ycombinator.com/item?id=18865242

>But now that there's another Web Browser layer slapped on top of X-Windows (and the terms "client" and "server" switched places), you're stuck with two competing mutually incompatible window managers nested inside of each other, one for the outside frames around apps, and one for the inside tabs around web pages, that don't cooperate with each other, and operate uncannily differently.

>So none of your desktop apps benefit from any of the features of the web browser (unless they include their own web browser like Electron).

>And you can't write lightweight apps in a couple pages of script like "Big Brother Eyes" that run in the shared window server, without requiring their own separate external app with a huge runtime like Electron.

https://www.donhopkins.com/home/archive/news-tape/fun/eye/ey...

>Nor can you easily integrate desktop applications and widgets and web pages together with scripts, the way HyperCard, OpenDoc, CyberDog and HyperLook enabled.

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

>Here's how the web browser and window manager should work together seamlessly:

https://news.ycombinator.com/item?id=18837730

>>Now Firefox and Chrome still need decent built-in universally supported and user customizable pie menus, but unfortunately the popup window extension API is inadequate to support them, because there's no way to make them pop up centered on the cursor, or control the popup window shape and transparency. Unfortunately they were only thinking of drop-down linear menus when they designed the API. (Stop thinking inside that damn rectangular box, people!)

>>But I remain hopeful that somebody will eventually rediscover pie menus in combination with tabbed window for the web browser, and implement them properly (not constrained to pop up inside the browser window and be clipped by the window frame, and not just one gimmicky hard coded menu that user's can't change and developers can't use in their own applications). But the poorly designed browser extension APIs still have a hell of a lot of catching up to do with what it was trivial to do in NeWS for all windows 30 years ago.

>And this is why a modern window manager should be written in JavaScript, leverage HTML, Canvas and WebGL, and support Accessibility APIs, as well as screen scraping, pattern recognition, screen casting, virtual desktops, overlays, drawing and image composition, input event synthesis, journaling, macros, runtime user customization and scripting, programming by demonstration, tabbed windows, pie menus, etc:

https://news.ycombinator.com/item?id=18797587

>[...] About 5 years ago I opened this issue, describing an experiment I did making the web browser in a topmost window with a transparent background to implement user interface overlays scripted in HTML.

>WebView window for HTML user interfaces like pie menus to Slate. #322:

https://github.com/jigish/slate/issues/322

>Slate used a hidden WebView for its scripting engine. So I made it un-hidden and float on top of all the other windows, and was easily able to use it to draw any kind of user interface stuff on top of all the other Mac windows. And I could track the position of windows and draw a little clickable tab next to or on top of the window title bar, that you could click on to pop up a pie menu.

>It actually worked! But I didn't take it much further, because I never got any feedback on the issue I opened, so gave up on using Slate itself, and never got around to starting my own JavaScript window manager myself (like you did!). I opened my issue in June 2013, but the last commit was Feb 2013, so development must have stopped by then.

>[...] Think of it like augmented reality for virtualizing desktop user interfaces and web pages.

https://news.ycombinator.com/item?id=5861229

>[...] So I adapted the "uwm" window manager to support pie menus, so you could define your own pie menus and linear menus in your .uwmrc file. Because a window manager could really benefit from pie menus: lots of the commands are spatially oriented and can be arranged in appropriate mnemonic directions, and they have a fixed set of common window management commands that can be thoughtfully arranged into a set of efficient pie menus, as well as a menu definition language to enable users to create custom menus for running apps, connecting with remote hosts, etc.

>[...] I had been using Mitch Bradley's "Forthmacs", which was a very nice Forth system for the 68k. (It eventually evolved into the Sun 4 Forth boot ROMS, OpenFirmware, and the OLPC boot ROMs). It was capable of dynamically linking in C code (well not dll's or shared libraries, but it would actually call the linker to relocate the code to the appropriate place in Forth's address space, read in the relocated code, and write Forth wrappers, so you could call C code from Forth, pass parameters, etc -- SunOS 4.2 didn't have relocatable shared libraries or light weight threads back then, so Forth had to do a lot of the heavy lifting to plug in C code. But Forth was a really great way to integrate a library into an interactive extension language, call it from the Forth command line, build on top of C code in Forth, call back and forth between C and Forth, play around with it from the Forth command line, etc).

https://news.ycombinator.com/item?id=16839825

>Inspired by HyperCard, we (old Sun NeWS hands) also pleaded until we were blue in the face to make HyperLook (a NeWS/PostScript/network based reinterpretation of HyperCard) the window manager / editable scriptable desktop environment!

https://news.ycombinator.com/item?id=18314265

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

>Alan Kay on NeWS:

>“I thought NeWS was ‘the right way to go’ (except it missed the live system underneath). It was also very early in commercial personal computing to be able to do a UI using Postscript, so it was impressive that the implementation worked at all.” -Alan Kay

>What’s the Big Deal About HyperCard?

>"I thought HyperCard was quite brilliant in the end-user problems it solved. (It would have been wonderfully better with a deep dynamic language underneath, but I think part of the success of the design is that they didn’t have all the degrees of freedom to worry about, and were just able to concentrate on their end-user’s direct needs."

>"HyperCard is an especially good example of a system that was “finished and smoothed and documented” beautifully. It deserved to be successful. And Apple blew it by not making the design framework the basis of a web browser (as old Parc hands advised in the early 90s …)" -Alan Kay

https://news.ycombinator.com/item?id=8546507

>HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;)

http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...

>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!

https://news.ycombinator.com/item?id=13785384

>>You can't do opengl efficiently over the network. At least xorg can't. Most applications uses opengl these days.

>Sure you can, it's just called WebGL! ;)

>They just added another layer, flipped the words "server" and "client" around, and added more hardware.

>Now you run the web browser client on top of the local window system server, through shared memory, without using the network. And both the browser and GPU are locally programmable!

>And then the local web browser client accesses remote web servers over the network, instead of ever using X11's networking ability.

>One way of looking at it in the X11 sense is that a remote app running in the web server acts as a client of the local window server's display and GPU hardware, by downloading JavaScript code to run in the web browser (acting as a programmable middleman near the display), and also shader code to run in the window server's GPU.

>Trying to pigeonhole practices like distributed network and GPU programming into simplistic dichotomies like "client/server," or partition user interface programming into holy trinities like "model/view/controller," just oversimplifies reality and unnecessarily limits designs.

https://news.ycombinator.com/item?id=20183838

>Imglorp> Hi Don! Tabs aside, NeWS got so many things right, and not just at the UI but the underlying idea of code instead of bitmaps. I wonder if we were going to start afresh with Wayland/X11 now, bare hardware, what place do you think the NeWS lessons would have? Would a modern NeWS be on top of PS or is there something better now?

>Hi Imglorp!

>Simply use a standard JavaScript / WebAssembly / WebGL / Canvas / HTML based web browser as the window system itself! And use WebSocket/SocketIO/RTP/HTTP instead of the X-Windows or VNC protocols.

>Microsoft kinda-sorta did a half-assed inside-out version of that with Active Desktop, but Internet Explorer wasn't powerful or stable enough to do it right, and it didn't eliminate and replace the whole Win32 / MFC layer, which misses the main point.

https://en.wikipedia.org/wiki/Active_Desktop

>There was recently this discussion about a browser based Mac window manager project (now offline), and there have been others like it (Slate), but the ideal goal is to completely eliminate the underlying window system and just use pure open web technologies directly on the metal:

>Show HN: Autumn – A macOS window manager for (Type|Java)Script hackers (sephware.com):

https://news.ycombinator.com/item?id=18794928

>Site archive:

https://web.archive.org/web/20190101121003/https://sephware....

Comments:

https://news.ycombinator.com/item?id=18797587

>I was also quite inspired by Slate. Unfortunately there hasn't been any activity with it for about 5 years or so. It's great you're picking up the mantel and running with it, because the essential idea is great!

https://news.ycombinator.com/item?id=18797818

>Here are some other interesting things related to scriptable window management and accessibility to check out:

>aQuery -- Like jQuery for Accessibility

https://web.archive.org/web/20180317054320/https://donhopkin...

>It would also be great to flesh out the accessibility and speech recognition APIs, and make it possible to write all kinds of intelligent application automation and integration scripts, bots, with nice HTML user interfaces in JavaScript. Take a look at what Dragon Naturally Speaking has done with Python:

https://github.com/t4ngo/dragonfly

>Morgan Dixon's work with Prefab is brilliant.

>I would like to discuss how we could integrate Prefab with a Javascriptable, extensible API like aQuery, so you could write "selectors" that used prefab's pattern recognition techniques, bind those to JavaScript event handlers, and write high level widgets on top of that in JavaScript, and implement the graphical overlays and gui enhancements in HTML/Canvas/etc like I've done with Slate and the WebView overlay.

>Web Site: Morgan Dixon's Home Page.

http://morgandixon.net/

Web Site: Prefab: The Pixel-Based Reverse Engineering Toolkit.

https://web.archive.org/web/20130104165553/http://homes.cs.w...

>Video: Prefab: What if We Could Modify Any Interface? Target aware pointing techniques, bubble cursor, sticky icons, adding advanced behaviors to existing interfaces, independent of the tools used to implement those interfaces, platform agnostic enhancements, same Prefab code works on Windows and Mac, and across remote desktops, widget state awareness, widget transition tracking, side views, parameter preview spectrums for multi-parameter space exploration, prefab implements parameter spectrum preview interfaces for both unmodified Gimp and Photoshop:

http://www.youtube.com/watch?v=lju6IIteg9Q

>PDF: A General-Purpose Target-Aware Pointing Enhancement Using Pixel-Level Analysis of Graphical Interfaces. Morgan Dixon, James Fogarty, and Jacob O. Wobbrock. (2012). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '12. ACM, New York, NY, 3167-3176. 23%.

https://web.archive.org/web/20150714010941/http://homes.cs.w...

>Video: Content and Hierarchy in Prefab: What if anybody could modify any interface? Reverse engineering guis from their pixels, addresses hierarchy and content, identifying hierarchical tree structure, recognizing text, stencil based tutorials, adaptive gui visualization, ephemeral adaptation technique for arbitrary desktop interfaces, dynamic interface language translation, UI customization, re-rendering widgets, Skype favorite widgets tab:

http://www.youtube.com/watch?v=w4S5ZtnaUKE

>PDF: Content and Hierarchy in Pixel-Based Methods for Reverse-Engineering Interface Structure. Morgan Dixon, Daniel Leventhal, and James Fogarty. (2011). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '11. ACM, New York, NY, 969-978. 26%.

https://web.archive.org/web/20150714010931/http://homes.cs.w...

>Video: Sliding Widgets, States, and Styles in Prefab. Adapting desktop interfaces for touch screen use, with sliding widgets, slow fine tuned pointing with magnification, simulating rollover to reveal tooltips:

https://www.youtube.com/watch?v=8LMSYI4i7wk

>Video: A General-Purpose Bubble Cursor. A general purpose target aware pointing enhancement, target editor:

http://www.youtube.com/watch?v=46EopD_2K_4

>PDF: Prefab: Implementing Advanced Behaviors Using Pixel-Based Reverse Engineering of Interface Structure. Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 1525-1534. 22%

https://web.archive.org/web/20150714010936/http://homes.cs.w...

>PDF: Prefab: What if Every GUI Were Open-Source? Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 851-854.

https://web.archive.org/web/20150714010936/http://homes.cs.w...

Morgan Dixon's Research Statement:

https://web.archive.org/web/20160322221523/http://morgandixo...

>Community-Driven Interface Tools

>Today, most interfaces are designed by teams of people who are collocated and highly skilled. Moreover, any changes to an interface are implemented by the original developers and designers who own the source code. In contrast, I envision a future where distributed online communities rapidly construct and improve interfaces. Similar to the Wikipedia editing process, I hope to explore new interface design tools that fully democratize the design of interfaces. Wikipedia provides static content, and so people can collectively author articles using a very basic Wiki editor. However, community-driven interface tools will require a combination of sophisticated programming-by-demonstration techniques, crowdsourcing and social systems, interaction design, software engineering strategies, and interactive machine learning.

arduinomancer4y ago· 4 in thread

So for someone who knows nothing about this stuff, how is Wayland different?

Arnavion4y ago

In general, wayland does not implicitly have a distinction between server and window manager. There is a server and there are clients. The server gets to decide where a particular client's windows are rendered. Wayland itself is just a spec of the protocol that the client and server use to talk to each other - the format of the messages, and a few documents that describe various such messages. What the server does is basically completely arbitrary.

I don't know about GNOME and KDE's wayland servers, but with sway and river and cage the server is a single process that does the job of both server and window manager. It doesn't mean everyone has to write the equivalent of an X server, ie code that interacts with OpenGL and the kernel interfaces, themselves - there is a popular library called wlroots that can be used for that.

I don't think it's impossible that someone wraps wlroots into a standalone "server" binary that then has its own protocol for talking to an arbitrary "window manager" binary at runtime. ie do the equivalent of what wlroots does with function calls and callbacks at compile time but at runtime via IPC. But I don't know anyone who's doing such a thing.

remix20004y ago

People have already mentioned wlroots as a starting point, but there is a less opinionated and more compatible (NVIDIA-ready) library that I’m really quite fond of called Mir: https://github.com/MirServer/mir

One thing to note, Wayland, unlike X, does not support server side decorations yet, so compositor’s responsibilities are mostly just placing windows.

Arnavion4y ago

SSDs are supported via xdg-decoration (unstable) https://wayland.app/protocols/xdg-decoration-unstable-v1

5e92cb50239222b4y ago

https://wayland-book.com

liveprogramming4y ago· 3 in thread

This is a great article and I remember reading it numerous times while I was implementing my own window manager.

For someone interested in working on a really fun and rewarding hobby project a WM is a great one to look into since there are so many resources starting from really small implementations:

- https://github.com/mackstann/tinywm

- https://github.com/venam/2bwm

- https://github.com/dylanaraps/sowm

- https://github.com/dcat/swm

- https://github.com/JLErvin/berry

Which are great at introducing the concepts and allowing you to grok the required libraries.

To larger more full featured packed window managers which will introduce you to more advanced topics:

- https://github.com/baskerville/bspwm

- https://github.com/herbstluftwm/herbstluftwm

- https://www.nongnu.org/ratpoison/

- https://github.com/conformal/spectrwm

Gradually as you get more familiar with the ecosystem a few questions will come up:

Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine.

X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun.

Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm

DonHopkins4y ago

I made an X10 window manager based on "uwm" in 1987, which had pie menus, and was extensible and scriptable in FORTH!

https://donhopkins.com/home/archive/piemenu/uwm/

https://donhopkins.com/home/archive/piemenu/uwm/Menu.c

https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f

I didn't see a bright future for X (and still don't ;) ), so I switched to NeWS, and began writing pie menus and window managers in PostScript.

NeWS (which was James Gosling's creation before Java and after Emacs) was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

Pie Menus and Tab Windows for NeWS in object oriented PostScript:

https://donhopkins.com/home/archive/piemenu/pieui/

NeWS Tab Window Demo:

https://www.youtube.com/watch?v=tMcmQk-q0k4

At Sun, we even used the above code to write an X11 ICCCM "Open Window Manager" in PostScript for X11/NeWS, which wrapped your X11 windows in NeWS tabbed frames with pie menus, implemented in PostScript, the same as all your NeWS windows used, all running in the same address space, and easily centrally customizable and extensible.

https://news.ycombinator.com/item?id=13817649

>At Sun we experimented with implementing an X11 window manager in NeWS. We didn't have transparency at the time (1992), but we did support shaped windows!

>The NeWS window manager supported cool stuff (for both X11 and NeWS windows!) like rooms, virtual scrolling desktops, tabbed windows, pie menus, was easily extensible and deeply customisable in PostScript, and ran locally in the window server so it could respond instantly to input events, lock the input queue and provide feedback and manipulate windows immediately without causing any context switches or dealing with asynchronous locking, unlocking and event handling. You'd never lose a keystroke or click when switching between applications, for example.

https://news.ycombinator.com/item?id=22456153

>And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm".

https://donhopkins.com/home/archive/NeWS/owm.ps.txt

>% Open Window Manager

    /ClassX11ManagerMixin ClassWindow
    [/IconWindow /WidthInc /HeightInc /FirstMapping]
    classbegin

        /NewInit { % client => -
            /NewInit super send
            self /WM_STATE xdeleteproperty % The frame is not a ICCCM window
        } def

https://www.donhopkins.com/home/archive/NeWS/sevans.txt

>Don> If you don't want to dump NeWS, then why have you been caused us so much trouble?

>Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment."

>Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run).

>We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could.

NeWS had its own problems, of course, but its biggest problems weren't technical, but political, and it wasn't free despite all the hard effort, spilled blood, and broken promises. But the consequences of that experience did help to make Java free, eventually. (But then Oracle later ruined worse than Sun ever could have.)

https://news.ycombinator.com/item?id=22457490

>James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS: [...]

>"We'll get it out, even if I have to spill some real blood on the floor." -James Gosling, on freeing NeWS, March 6, 1990

>[...] It has been very clear for a long time that DEC explicitly targeted NeWS as something to be trashed. That was probably the major reason for giving NeWS such a ridiculously low profile. There were folks at sun who didn't want to give DEC a bigger target. The folks running the show now have more guts.

>James.

https://www.donhopkins.com/home/archive/NeWS/flame.txt

>November 11, 1990:

>I have been hoping for Sun to make Open Windows free since it was called SunDew, and during that time, I've made it perform many indescribable acts (both on and off stage), worked with quite a few companies trying to make it a succeess, and drained much much more of my energy than I ever knew I had to give into that incredible piece of software.

>I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free".

destructionator4y ago

nitpick but X11 is the protocol XCB speaks. You're probably speaking of Xlib which is a bit of a higher level library over the top of it (but... not really that much higher, for a great many tasks there's no real difference).

mcguire4y ago

Don't forget that X includes X-in-X servers, Xnest/Xephyr, that mean you don't have to live in your WM while you build it.

Is there similar functionality for Wayland?

ninjin4y ago· 2 in thread

Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be used as a daily driver. It only took me about an hour or two to develop two patches that changed the layout to my liking. Plus, I have found the people in #suckless over at the OFTC IRC network to be very kind and helpful.

[1]: https://dwm.suckless.org

[2]: https://git.suckless.org/dwm/files.html

Jasper_4y ago

Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM.

[0] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm... , the standard for how X11 clients and WMs should communicate.

ninjin4y ago

Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1].

[1]: https://dwm.suckless.org/patches/steam

1 more reply

shadowfox4y ago· 2 in thread

Slightly orthogonal to this: is there a good tutorial on writing your own simple Xserver?

dfox4y ago

https://magcius.github.io/xplain/article/x-basics.html

Last time I checked it was work in progress and I'm not sure how complete it is at this moment, but it includes understandable explanations of the low-level algorithms and acceleration structures involved.

Edit: this shows how X works from the lazout and graphical side. One interesting thing that is not covered by this is the somewhat peculiar wire format of X11 connection (it was obviously designed by someone with LISP background).

loxias4y ago

I don't know about a tutorial, but I learned a lot from the xvfb and xvnc code.

phendrenad24y ago· 2 in thread

No mention of sockets? I'm surprised. That's the real tricky part of writing an X11 server...

emersion4y ago

This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).

mcguire4y ago

Sockets? Not the whole "dealing with graphics hardware" thing?

fmakunbound4y ago· 1 in thread

I used to write an X11 window managers as a kick-the-tires exercise when learning a new language. The most fun one was Common Lisp with CLX. You could stay in the WM and code it live. When something went wrong you could continue after making fixes. It’s what lead me to Common Lisp being my favorite language going on decades now.

hulitu4y ago

There was a window manager (gwm) written in a lisp dialect (wool). It was very nice.

low_tech_love4y ago· 1 in thread

Funny, yesterday someone posted an article about an Ada-based X implementation, and I thought “could be fun to write my own X”. I guess I wasn’t the only one!

forgotpwd164y ago

For anyone that may have missed it: https://news.ycombinator.com/item?id=29077750

nerdponx4y ago

Even if you don't intend to write your own WM, I think this article is a great reference for understanding how X works in general.

thuccess1294y ago

Plan 9's rectangle multiplexer, rio, needs an X11 mouse gesture addon for consistent Desktop Environment Application clipboard with Emacs's do/undo versatility.

rnd04y ago

I did not know I needed this until I saw this headline. I feel a new personal tangent coming on -thanks!

j / k navigate · click thread line to collapse

244 comments

61 comments · 13 top-level

fyrn-4y ago· 23 in thread

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

linguae4y ago