When I'm unfamiliar with the internals of a piece of software, it can seem like black magic; but it's illuminating to see something you didn't know break down into familiar steps. When the rationale behind the steps and the secret sauce -- business logic -- between them is explained incrementally, my understanding of the system grows even more, so I love posts like this.
However, can you say a few words about why one would want to a write an alternate Wayland compositor professionally (i.e. reasons other than learning and exploration) -- as in: does the protocol offer places where meaningful feature differentiation can be achieved, while still achieving full compliance?
The existence of something like 'wlroots' to me is an indicator that prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate?
Aside from handling details on how the actual drawing happens, Wayland compositors also dictate how window management is done. Obviosly, there is a lot of room for different designs in that space. Just look at how many different Window Managers there exist for X. My understanding is that wlroots handles a lot of heavy lifting related to drawing and input handling making experimentation with new compositors a lot easier.
wlroots is designed to support many different user interaction paradigms. Many Wayland compositors do share the same nuances, sure, but many do not. In addition to the typical desktop experience, you can use wlroots to make a compositor which arranges windows in 3D space for VR, or make a compositor that runs a phone interface, or a dashboard for a car, or any number of other use-cases.
Even within the desktop paradigm, there's a lot of variance and room for compositors to specialize, but it's more subtle.
I'm still waiting for someone to make a wayland compositor that compares to compiz. One super important feature I use every day is being able to invert a SINGLE window and not the entire screen.
For all the "omg it's slow" posts about compiz and x-server, it's fast enough to run on my netbook with a 5-watt processor.
> One super important feature I use every day is being able to invert a SINGLE window and not the entire screen
While it's not per window inversion, for years I've been using the tiny (100KB) and wondrous xcalib package for screen inversion*
Should note that in order to get per screen inversion working I need to use Nvidia's Xinerama extension (without this extension inversion happens across all screens).
* bound to alt-o/alt-i hotkeys with xbindkeys. Here's the .xbindkeysrc if anyone's interested.
I haven't tried it recently but if kde has gotten better on Wayland it might offer this feature. You can set a compositing effect for this in x11 with it last I looked. But last time I tried kde Wayland it was far from stable.
GNU Emacs is a text editor, extensible in Emacs Lisp.
A Lisp Machine usually is a real computer - one with an OS written in Lisp.
GNU Emacs OTOH is hosted on an OS and doesn't even have multiple threads. It's more an application development and execution environment, for applications based on Emacs text-buffer abstraction.
The actual Lisp operating system user interfaces were not built on a text-buffer abstraction.
Which Lisp Machine is GNU Emacs emulating? Actually existing ones or a conceptual model of a 'Lisp Machine'?
If we look at the existing ones, there were two main ones: Interlisp-D based systems from Xerox and the MIT Lisp Machine and its later variants from LMI, Symbolics and TI. There were a bunch of lesser known ones, which didn't have much influence. Both the Xerox Lisp Machine and the MIT Lisp Machines have emulators - they allow you to run them usually on some Unix/Linux + X11. None of them had any sophisticated terminal capabilities - all were needing/providing a full GUI environment.
If you boot a Symbolics, it starts into a GUI environment with a Listener as the console. This Listener is not an editor window and it is not text only - it supports full graphics and mouse input. The listener runs commands and Lisp forms. The commands are providing typical servives like a login command, listing directories, copying files, enabling and disabling of network services, reading tape drives, compressing files and more. Editing files is usually done in a text editor, which is actually an Emacs called Zmacs. Applications are usually fullscreen windows with subpanes. These subpanes are arranged by layout descriptions provided by the application. But the window system is actually also providing the ability to have overlapping windows or multiple windows on the screen or even windows composed of subwindows. The implementation of all of this is heavily object-oriented using something like Flavors, New Flavors or, later, CLOS.
If you look at GNU Emacs, it does not provide a GUI-first environment, its basic abstraction is the text buffer and a UI representation of that in a terminal or a window. You don't login into GNU Emacs. Its programming model is different, since it doesn't use OOP at its core. It's not multithreaded.
The main similarities to the MIT Lisp Machine OS: they appear to be text-based (which the MIT Lisp Machine uses a lot, but in different ways and mostly not editor-based), there programming and extension languages are variants of Maclisp, they provide things like REPLs, Lisp code execution, Lisp debugger, Lisp interpreter, etc... But all the latter is also provided by Multics Emacs written in Maclisp in the late 70s. These are not features of a Lisp Machine, but generally the features of a typical Lisp system. The Lisp Machine extended this with real GUIs, real OS code written in Lisp (like serving network interfaces, event handlers, frame buffer interfaces, file systems, process schedulers, dumping memory to create worlds which can be booted into, ...)
The main reason the Lisp Machine existed was that they were a fast track to personal workstations for AI programmers/researchers and the groups knew Lisp, it was a good prototype environemnt for them, and they could built such personal workstations within a few years.
But interactive Lisp systems existed before and after. Before usually on 'mainframes' (see Interlisp with its terminal-based tools) and after that on many types of machines: like UNIX workstations and Windows-based personal computers
Now: what parts of GNU Emacs make you think that it emulates a Lisp Machine? Is it emulating real existing ones or parts of them? Is it emulating comcepts? Concepts which probably existed also outside of Lisp Machines in interactive Lisp systems?
However, can you say a few words about why one would want to a write an alternate Wayland compositor professionally (i.e. reasons other than learning and exploration) -- as in: does the protocol offer places where meaningful feature differentiation can be achieved, while still achieving full compliance?
The existence of something like 'wlroots' to me is an indicator that prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate?