[ANN] Rivulet Window Manager

So, with respect to backends, it seems there are two decisions to make here. First, decide on how we speak the Wayland protocol:

1. The one-to-one translation of wayland-scanner generated code, and bound into Haskell via FFI.
2. Event stream approach built around the wayland-scanner. This could be sped up a fair amount if we could have the stuff I’m writing manually automated. This would give us a cleaner implementation, allow unit-testing and so-forth.
3. Event stream completely generated in Haskell.

Second, decide whether we want to be:

a. a River window manager. b. a Wayland compositor

(3b) would of course be the nicest to have. It would allow us to do some weird things like layouts for background layers, and allow users to chose what protocols to implement. (One of the drawbacks of River is that we’d need a side-channel to pass on workspace/tag info to tools like Waybar). The disadvantage is that it is a big project. My feeling is that it would take a year or so to get to a` daily-driver level. So, I’m leaning heavily to the (a) options. River seems like a great incubation space until we’re mature enough.

(1a) is the approach you’ve taken. The major advantage here is that you’ve got something pretty close to a daily driver. In the long run I’m not too keen on this approach though, because it feels like writing C in Haskell, testing is hard etc. You seem to feel the same. What is your feeling on transitioning from your implementation to a (2a)/(3a) approach? Is doing so incrementally a possibility, or would it make sense to re-implement from scratch and pull in the code for the DSL etc later?

Down the road, I think transitioning from (3a) to (3b) should be reasonable without throwing away too much if we choose our abstractions well.

There seems to be a bunch of trial and error that needs to happen to get to (3a). Though, the event stream abstraction should isolate the protocol implement from the rest of the code base.

So, my feeling is that it would be easiest to get something working with the (2a) approach so that we have something to show as soon as possile, and then transition to (3a) once we’ve got some momentum going (relatively soon hopefully). Eventually, once we start feeling River’s limitations, we can transition to (3b).

Does that seem sensible to you?