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