How can we help?

[cedws]

How can we help?

[Timidger]

Hi there!

Right now I'm very busy with non Way Cooler related things right now (and soon won't be able to work on Way Cooler at all in a few weeks. A blog post will soon explain why), so I won't be pushing much code but I'll be here to review/merge PRs and on #awesome to answer any questions.

There is a branch of the last changes I was making, which was addressing the issues raised in #561. It is quite a big change though and still not complete (I don't want to merge it in until it can do the same things as master). For the most part the branch can be ignored, but if you want to know more wait for that previously mentioned blog post.

There are roughly two components that need to made for Way Cooler: the compositor part (that actually handles the Wayland and drawing stuff) and the Awesome part (which needs to provide an API that's called from Lua identical to the one defined by Awesome). Right now it's entirely possible to work on the Awesome part without having to know much about Wayland (and I can fill in any gaps that come up). Essentially you look at the API defined by Awesome and implement it in Way Cooler using Rust.

For examples of already implemented APIs, check out the awesome/ folder. For examples of what needs to be implemented, check out these issues

If someone is more interested in working on the compositor bit, they should read up on wlroots and wlroots-rs. I've been trying to keep wlroots-rs up to date, but a pull of the wlroots-rs/wlroots/ submodule might break things. That should be fixed sooner rather than later. Working on wlroots-rs is very hard since it is entirely unsafe Rust code and has a complex memory model. That doesn't mean you can't contribute to it, just that the standards will be higher and I will take longer to review your PR (and the code will be confusing to those who don't understand the Wayland memory model - again, ask questions!).

On the Way Cooler compositing side, in order of difficulty:

• XWayland shells still aren't implemented, and that would be relatively easy thing to do.
• xdg shell still needs to be implemented (the best documentation on how that works is the xdg-shell protocol itself and the implementation in wlroots' Rootston).
• A protocol to have the two pieces talk to each other in my branch will be necessary, but requires knowledge of Wayland protocols. For help on this, it's better to ask someone else on #sway-devel (Because I also have never pushed for a Wayland protocol, and the folks there will know better than I). I will probably end up doing this, though I welcome help 😄.

One should read the Wayland documentation if you want to understand how to use wlroots and Wayland better. Feel free to also ask questions to me or on #sway-devel (which I am also active in and where all wlroots and wlroots-rs related questions should be sent).

[acrisci]

How's the split up going? I was waiting on that to be stable to jump back in.

[Timidger]

@acrisci

I wanted to get more work done on it (i.e get it to where it was before with features) but I'm going to merge it to master since I have so little time left.

#568

It doesn't render the top bar any more, but that is just work that needs to be done in awesome/ to use the xdg-shell protocol.

A custom protocol will need to be designed for the other functions. Later we can try to split it up and suggest it to other compositors.

[Timidger]

As an update, the split up is much more stable. The major work left on the compositor side of things:

• Implement the rest of the regular boring compositor stuff, this includes wrapping things in wlroots-rs.
  • E.g. we need to hook up data device, touch devices, layer shell, etc.
• Design a protocol for the extended set of features Awesome will need. I want to borrow from the wlroots proposed protocols before using a custom solution in most cases, as it will be easier to rely on those and reduce our "special" protocol code as much as possible (if only so we can have a simpler protocol to propose as a possible standardization later if we can make it flexible enough for use outside Way Cooler).

On the Awesome side it's the same as it's always been, though one thing I'm going to work on next to make it easier is set up the testing framework so we can actually have measurable progress towards how much of the API we need to implement.