Sway support

[markstos]

Adds sway support.

It uses the "swayipc" library, which supports both Sway and i3.

[svenstaro]

Thanks! I'd really like to support sway. How to we get stuff drawn on wayland though? In my understanding, this is only the control logic and not the drawing logic.

[markstos]

Instead of using X-specific code, use winit, a cross-platform Rust library which supports both X and Wayland by default.

https://github.com/rust-windowing/winit

[svenstaro]

@markstos When I initially implemented this, I tried using winit first but I concluded it didn't have exactly the capabilities required. If you like, you can try to take a stab at this in order to make it work using winit which is definitely preferable. Maybe the situation has changed by now.

[markstos]

@svenstaro Although I thought I could read Rust well enough to do this rebase, I haven't started doing Rust development yet and wouldn't be able to get to this soon, but maybe @JayceFayne could take a look. If you are able to recall which features it was missing at the time, perhaps we can check the Changelog to see if they have been added since then.

[svenstaro]

I honestly don't remember, it was a long time ago. I guess the most efficient way is to just attempt it and see how far you can get. I suppose this is actually a fairly nice way to learn Rust as the project is rather small and it's also a thing you'd supposedly use yourself. I'm happy to do reviews.

[markstos]

I'm interested to learn Rust, but this my first day back from a work vacation so I expect to stay busy catching up with things for a while. I'll keep this in mind as a first Rust project!

[markstos]

@svenstaro I have successfully rebased the Sway support off of the main branch, resolved all the conflicts and tested that it works with Sway. 🎉

I can say this about the if node.window.is_some() { line: The Sway branch seems to work fine without the conditional. However, I tried adding it back and on the Sway branch, and wmfocus does not work at all with that conditional included. It hangs.

If you could re-test with the Sway support didn't break the i3 support, I think this is ready for release.

Note, this branch also now depends on the swayipc 3.0.0 package instead of the Git repo.

Yes, the windows are still being drawn with X11, but 99% of of Wayland users are also using XWayland and won't notice or care about the difference. This is still a good step towards impoved Sway and Wayland support. Releasing this milestone may help attract the next Rust+Wayland developer to take on the "winit" refactor or otherwise add native Wayland drawing support.

[svenstaro]

Running this, I'm getting thread 'main' panicked at 'Problem communicating with IPC: SerdeJson(Error("missing field layout", line: 1, column: 153))', src/wm_i3.rs:101:10 on i3.

Also sorry for the inactivity, I'd really like to get this merged soon! If you have some time to work on it, I'll provide quick feedback from now on.

[markstos]

@svenstaro Are you running it with Sway/Wayland or i3/X11 when you get that error? I don't get it with Sway.

Seems like the data structure returned by the two APIs must differ.

If so, the place to fix that might be in the swayipc-rs package: https://github.com/JayceFayne/swayipc-rs

[svenstaro]

I'm using straight i3.

[markstos]

I think I understand the root case, but so far I've only learned enough Rust to get this code that @JayceFayne wrote into the current state. 😂 Here's my guess about what's happening:

One difference between the Sway and i3 protocols is the format of the call to get_workspaces. The documentation what i3 returns is here:

https://i3wm.org/docs/ipc.html#_workspaces_reply

Sway documents their structure in man sway-ipc, Here's an example of what I see Sway actually returning:

❯ swaymsg -t get_workspaces
Workspace 4
  Output: eDP-1
  Layout: splith
  Representation: H[FirstApp]

Workspace 5 (off-screen)
  Output: eDP-1
  Layout: splith
  Representation: H[SecondApp]

I'm noticing that a "Layout" value is returned, which is the same field reported as "missing" in i3.

There's definitely a "layout" property for both i3 and Sway for i3 calls to "get_tree".

I suspect the i3 code is iterating over the results of a call to get_workspaces() (which doesn't contain a "layout" field) when it should be iterating over a call to get_windows() instead.

It would be helpful to confirm: is the IPC connection actually working with i3 and returning JSON, or is the error message accurate and the problem has to do with the presence or absence of the layout field? I checked the bug queue for the swayipc-rs package. Both i3 and Sway useres are definitely using the package, but no one is his reported this interoperability problem.

[markstos]

There is another way to resolve this, which is to rename wm_i3.rs to wm_sway.rs, and use wm_i3.rs from the trunk. In this approach, sway would be considered a separate "feature" would no longer try to use the same IPC code as i3.

i3 would return to depending on i3-specific IPC library and Sway would use the swayipc library.

Yes, there would be some duplication of code, but the assumption that the Sway and i3 IPC approaches are compatible would be removed. Someone could then safely update the Sway code without worrying it would break i3 or vice versa.

Currently we have a developer collaboration challenge because the i3 devs don't use Sway and the Sway devs don't use i3 and no one is excited about installing and testing with both.

I think that may be the best way forward.

[markstos]

@svenstaro Do you have feedback on the alternate approach I suggested above of keeping the i3 and Sway support separate? It's a bit of code duplication but I think it may be easier to maintain.

[svenstaro]

I'll revamp the plugin system in wmfocus in a bit. I think the current way is likely ill-designed in hindsight. Shouldn't be too bad. I might even set up a sway setup on a system to test this with. Stay tuned, sorry for the delay.

[markstos]

@svenstaro Any luck with your Sway setup?