Port BerryWM from Xlib to Wayland

[AnirvanB]

First off, thank you for sharing this incredible work with the community! I recently discovered this gem and have been impressed by its performance and capabilities.

To stay current with Linux ecosystem advancements, porting the codebase from Xlib to Wayland is essential. This transition will improve performance, security, and compatibility with modern systems.

Requirements:

• Replace Xlib dependencies with Wayland equivalents.
• Maintain feature parity with the current implementation.
• Test across various Wayland compositors to ensure broad compatibility.

Please share your thoughts on this, potential challenges and an estimated effort/ timeline for this task, should you decide to go down the re-implementation route.

Thanks again for this fantastic project! ♥️

[JLErvin]

First off, thank you for sharing this incredible work with the community! I recently discovered this gem and have been impressed by its performance and capabilities.

To stay current with Linux ecosystem advancements, porting the codebase from Xlib to Wayland is essential. This transition will improve performance, security, and compatibility with modern systems.

Requirements:

• Replace Xlib dependencies with Wayland equivalents.
• Maintain feature parity with the current implementation.
• Test across various Wayland compositors to ensure broad compatibility.

Please share your thoughts on this, potential challenges and an estimated effort/ timeline for this task, should you decide to go down the re-implementation route.

Thanks again for this fantastic project! ♥️

This would be lovely, but it would be a rather large undertaking that I'm not sure I can commit to. Unfortunately, for the most part, the behavior of berry is pretty tightly coupled with XLib. Creating a Wayland port of berry would involve something like the following

1. Refactor the codebase such that the window management logic uses a well-defined interface to do things like draw, resize, and move windows.
2. Port the existing XLib functionalities to use this interface (i.e. implement an XLib backend)
3. Create an implementation of this interface that uses Wayland instead of XLib.

(3) is the tricky part, as I'm almost certain that there will not be feature parity between (2) and (3). Something like the scenes API in Wayland will probably be helpful there, but I would need to do more research to know that such functionality is possible. berry also uses some hacks with the X11 server that I would need to verify work on Wayland. For instance, setting the font with berryc requires directly setting properties on the X server and then sending an IPC message to let the server know this value has changed.

If anything, I'd prefer to rewrite berry in a more modern language, like Rust, for a Wayland version. Last I checked there weren't any maintained libraries for this either.

This is something that, at a minimum, would require a couple weeks of effort on my end that I don't know would be worth it. Wayland has been on the horizon for years, but I still don't really see X going away anytime soon.

[AnirvanB]

Thanks @JLErvin, for the detailed breakdown of the complexities involved!

I understand porting berry to Wayland is a big task, especially with the XLib dependencies. However, libraries like Smithay for Rust could help with the Wayland implementation, handling much of the low-level work. Plus, tools like swhkd already exist for Wayland, which might simplify things further.

If you ever consider exploring it, these resources could make it more manageable. And if there’s anything I can do to convince you to pick it up, just let me know—berry on Wayland would be an incredible upgrade!