Conversation
Implement first-class MangoWC compositor support via mmsg IPC. This adds backend detection, listener loop, and command dispatch mapping for MangoWC while preserving existing Hyprland and Niri behavior. Changes include: - add new mangowc backend module with state fetch + watch stream handling - wire Mango backend into compositor backend detection and dispatch routing - extend shared compositor types with Mango active window variant - add multi-active workspace IDs in compositor state to support tag masks - keep Hyprland/Niri compatibility by populating active_workspace_ids This commit focuses on backend/service-layer integration only; UI behavior and docs are handled in follow-up commits. Signed-off-by: Sachin Bhat <sachubhat17@gmail.com>
Update workspace state derivation to consume multiple active workspace IDs. Motivation: - MangoWC supports multi-tag selection and can report more than one active tag. - Ashell previously assumed a single active workspace. What changed: - use active_workspace_ids when available and fall back to active_workspace_id - apply multi-active matching in both normal and virtual-desktop paths - keep visibility/ordering behavior unchanged Result: - active workspace rendering now works correctly for multi-tag compositors without regressing Hyprland/Niri behavior. Signed-off-by: Sachin Bhat <sachubhat17@gmail.com>
Refresh docs/site copy to reflect MangoWC support alongside Hyprland and Niri. Updates include: - README and intro wording expanded to include MangoWC - feature bullets updated for active window/workspaces/keyboard layout coverage - keyboard module docs note keymode-based submap behavior on MangoWC - window title docs clarify InitialTitle/InitialClass remain Hyprland-only - Docusaurus tagline and homepage metadata updated for consistency This commit is documentation-only and does not change runtime behavior. Signed-off-by: Sachin Bhat <sachubhat17@gmail.com>
Sachin-Bhat
changed the title
|
Happy to test the change on niri so nothing breaks Could you share a screenshot how the multiple active ids look now? |
|
Hey @clotodex, Thank you for pitching in! I can definitely share what I mean in a screenshot with some additional info. In mango multitag views are possible. Though I dont have it explicitly bound to a keybind in my dotfiles, I did the following: I ran this: mmsg -s -d view,1
mmsg -s -d toggleview,2
mmsg -g -t
eDP-1 tag 1 1 1 1
eDP-1 tag 2 1 1 0
eDP-1 tag 3 0 0 0
eDP-1 tag 4 0 0 0
eDP-1 tag 5 0 0 0
eDP-1 tag 6 0 0 0
eDP-1 tag 7 0 0 0
eDP-1 tag 8 0 0 0
eDP-1 tag 9 0 0 0
eDP-1 clients 2
eDP-1 tags 3 3 0
eDP-1 tags 000000011 000000011 000000000before taking the screenshot.
Here tag 1 and 2 are active as per the terminal output and ashell correctly shows both tags/workspaces active at the same time which was not possible earlier. |
|
Do let me know if you need any clarifications. I would probably need some assistance in having this tested in Niri and Hyprland to ensure that there are no regressions. |
|
I dont know how mango does multi monitor but you probably should test that as well (since the workspaces module was recently rewritten to allow for that) - should probabky just work though Otherwise looks good :) Testing on niri now |
|
Works on niri :) |
Thanks for raising this. I currently don’t have access to a multi-monitor MangoWC setup, so this PR focuses only on correctness for the single-monitor IPC surface for now. The backend is structured to remain compatible with future multi-monitor support, especially since MangoWC exposes output-scoped information through Given that, I’d prefer if this PR isn’t blocked on full multi-monitor support. Once I can test on an actual multi-monitor MangoWC setup, I’ll follow up with a PR that adds proper per-output handling (active/occupied/urgent masks, focused output state, layouts, etc.). If any collaborators or maintainers do have a multi-monitor MangoWC environment, I’d really appreciate help capturing the IPC outputs. Otherwise it would be nice to start a review :) |
|
I agree with the General Sentiment of not blocking this PR unnecessarily for every single detail. But I would love to have a best effort implementation that then can be improved. I can through Nix definitely check if I can run Mango in a very simple setup and test that it generally works. But I guess that given that you've checked the IPC output so far you should be able to kind of arrive at a best effort implementation that then I can just test and then that should be fine. But every single edge case we probably won't capture, that is then to me a better next PR. What do you think is needed for minimal multi monitor? |
|
Hey @clotodex sorry was a little occupied the past few days. Thanks, this makes sense and I agree with the scope. I’ll keep this PR as a best-effort implementation and avoid blocking on every edge case. Concretely, next step in this PR:
I won’t expand scope beyond that in this PR (window/title/layout/etc), and we can follow up with additional edge-case hardening in a separate PR after your nix validation. |
|
I have a tesing MangoWC setup with dual monitor. I've done two separate .conf files each with it's own "outputs". I have tag 1-5 at one monitor and 6-9 on the other. Both ashells show all tags and not only tags that belong to the monitor no matter what setting I choose for visibilty_mode. Both bars also show only the active tags from one monitor (currently 6+9 form the right one). Mouse clicks are only taken on the right panel, the left one does not respond to any input. |
|
Thanks for this new feature. I will not merge it into the next release at this time. After the release of the new version, we can proceed with the inclusion of the mangoWC support |
| pub active_workspace_id: Option<i32>, | ||
| pub active_workspace_ids: Vec<i32>, |
There was a problem hiding this comment.
Maybe we should maintain a single field here: active_workspace_ids should be the only field.
- hyprland/niri: will check only if it is empty or the first value in the
Vec. - mangoWC: should do what it does
I prefer this solution instead of this kind of thing active_workspace_ids: active_workspace_id.into_iter().collect(),
If we really want, we can create an ActiveWorkspaces wrapper struct with methods to simplify getting information, but maybe it's an overkill
| pub fn is_available() -> bool { | ||
| StdCommand::new("mmsg") | ||
| .args(["-g", "-O"]) | ||
| .output() | ||
| .map(|out| out.status.success()) | ||
| .unwrap_or(false) | ||
| } |
There was a problem hiding this comment.
This seems fragile and could hang. There's no other solution?
|
|
||
| let mut active_workspace_ids = active_workspace_ids.into_iter().collect::<Vec<_>>(); | ||
| active_workspace_ids.sort_unstable(); | ||
| active_workspace_ids.dedup(); |
There was a problem hiding this comment.
Why dedup? I mean active_workspace_ids is a hashset, so no duplicated values. We create a vec from that hashset, so no duplicated values, then sort, and then dedup. Probably it is not needed.
| let tags_raw = run_mmsg(["-g", "-t"]).await?; | ||
| let outputs_raw = run_mmsg(["-g", "-O"]).await?; | ||
| let active_client_raw = run_mmsg(["-g", "-c"]).await?; | ||
| let keyboard_raw = run_mmsg(["-g", "-k"]).await?; | ||
| let keymode_raw = run_mmsg(["-g", "-b"]).await?; |
There was a problem hiding this comment.
here we could use a tokio::try_join! to run them concurrently
4 participants
Hi @MalpenZibo,
Owing to the roadmap (#450) where you intended to support more compositors I took a crack at implementing support for MangoWC's ipc system i.e
mmsg. Mango is a tag-based compositor rather than a workspace based compositor which also supports multiple active-tags. From what I could see the assumption earlier was only one active tag/workspace at any time. I introducedactive_workspace_idsto indicate this with a fallback to the old behavior when multi-tag isn't present. I have added the relevant docs too. This was tested onmango 0.12.3(cea2bca)and this seems to work.Would appreciate any feedback!
Thanks
Sachin