The plugin based model has not taken off. In my opinion, this model has its merits however libweston did not give enough control to merit the simpler codebase that would result from using it. Something similar could be done today by building on top of wlroots.
Wayfire is a very plugin-based compositor built on wlroots. We have wobbly windows, desktop cubes, fire animations (naturally), tiling, all the things. Join us! :)
Very nice writeup, though I’m sorry to see it. I very much want something like AwesomeWM for Wayland; Sway is a little too hardcore-minimal for my tastes, and I really like Awesome as a slightly more forgiving WM that I don’t have to spend (as many) hours customizing.
I don’t think the author should feel bad about this though. They tackled a very ambitious project without a clear set of design goals, and were persistent and generally competent: Way Cooler is on most of the lists of Wayland compositors I’ve found. They fell into several classical traps of managing software projects, as outlined in this post, but always for laudable reasons. The only real mistakes they made were all from lack of experience. Doing all this while still also full time as a student? I only wish I had been able to do something like that.
They were also a victim of immature tools, as I remember long debates about soundness in hlua and rlua when both were new and fresh, and the author of hlua sadly concluding that its goal of a purely safe wrapper of the Lua FFI was impossible. Rust was in a similar boat: lots of people in the broader Rust community can now give you various answers for questions like “how do I write a tree with parent nodes and make it not awful to use”, but in 2016 that was not the case. And it sounds like the Wayland libs were in a similar state, so they were not alone on that front either.
In the end, these lessons look very useful for other people wanting to write Wayland compositors in Rust, and for people working on ambitious software projects in general. Thanks for all your effort, and as you say, until the next adventure.
A nice writeup and I’m sure a lot of people can identify with this kind of “burn out” on a project. Especially going through so many rewrites/redesigns is a typical pitfall that traps many young developers. I’m impressed the author managed to keep at it for 4 years, that’s quite a long time.
heh, I’ve tried to do something with libweston and Rust in 2018.
Wayfire is a very plugin-based compositor built on wlroots. We have wobbly windows, desktop cubes, fire animations (naturally), tiling, all the things. Join us! :)
Very nice writeup, though I’m sorry to see it. I very much want something like AwesomeWM for Wayland; Sway is a little too hardcore-minimal for my tastes, and I really like Awesome as a slightly more forgiving WM that I don’t have to spend (as many) hours customizing.
I don’t think the author should feel bad about this though. They tackled a very ambitious project without a clear set of design goals, and were persistent and generally competent: Way Cooler is on most of the lists of Wayland compositors I’ve found. They fell into several classical traps of managing software projects, as outlined in this post, but always for laudable reasons. The only real mistakes they made were all from lack of experience. Doing all this while still also full time as a student? I only wish I had been able to do something like that.
They were also a victim of immature tools, as I remember long debates about soundness in
hluaandrluawhen both were new and fresh, and the author ofhluasadly concluding that its goal of a purely safe wrapper of the Lua FFI was impossible. Rust was in a similar boat: lots of people in the broader Rust community can now give you various answers for questions like “how do I write a tree with parent nodes and make it not awful to use”, but in 2016 that was not the case. And it sounds like the Wayland libs were in a similar state, so they were not alone on that front either.In the end, these lessons look very useful for other people wanting to write Wayland compositors in Rust, and for people working on ambitious software projects in general. Thanks for all your effort, and as you say, until the next adventure.
A nice writeup and I’m sure a lot of people can identify with this kind of “burn out” on a project. Especially going through so many rewrites/redesigns is a typical pitfall that traps many young developers. I’m impressed the author managed to keep at it for 4 years, that’s quite a long time.
Great write-up! But is it actually a post mortem?
What were the lessons learned? What anti-patterns did you identify as a result of the experience?