feat: rename sway_mode to bindmode and add Hyprland support

[Rodrigodd]

I am currently migrating from sway to Hyprland, and so I added support for Hyprland in the sway_mode module. Because the module is no longer sway-only, I decided to rename to a more generic name. This feature does not have a consistent name across window managers, i3/Sway calls it binding mode, while Hyprland calls it Keybind submaps. But "bindmode" appears to be a good enough name.

I made "sway_mode" be a alias for "bindmode" to avoid breaking configs that use the previous name, but I can remove that if you prefer.

[JakeStanger]

Thanks for this.

There may be some conflicts with #836, which I'm looking to merge soon, which will relate to the client code. I'd also like to ensure that there's consistency between this, the workspaces and keyboard module so I will hold off a full review until that's merged.

[JakeStanger]

#836 is now merged & has created the expected conflict

[Rodrigodd]

@JakeStanger I rebased the PR over master.

My code has a very different style compared to the workspace and keyboard layout mode. I just query both compositors on module creation, choosing the first one that does not error out, while the other modules create a trait over the Compositors.

I found the second approach too complex to be worth it in this case. I started implementing it anyway for consistency's sake, but I noticed that the features for the keyboard module are slightly broken (matches become non-exhaustive if you disable one of the features, and part of the code depends on "workspace," but it is not listed as a dependency).

So for now, I will wait for your opinion.

[JakeStanger]

I just query both compositors on module creation, choosing the first one that does not error out, while the other modules create a trait over the Compositors.

The issue with your approach is that the module code is now coupled to, and responsible for, compositor-specific logic. This makes future changes more difficult, and could lead to the code getting more unwieldy if say support for another compositor was added. Eventually there may also be a Wayland protocol so that the bar does not need to rely on compositor-specific IPCs.

Ideally, the modules should have no idea what compositor or protocol or whatever the client is talking to. They should just say "get me the client for X", get the instance, and be able the blindly call the methods on the interface.

The other issue I have is that it duplicates some of the logic - there is already a function for getting the current compositor (which isn't exception based so is preferable).

tl;dr going the trait route avoids duplication and makes it easier to make changes in future.

I noticed that the features for the keyboard module are slightly broken (matches become non-exhaustive if you disable one of the features, and part of the code depends on "workspace," but it is not listed as a dependency).

That's an issue I missed, cheers for letting me know. The two should be decoupled from each other, so I'll have a look at that.