feat(ipc): add per-client tag event to zdwl_ipc_output_v2 v3#887
Open
dashdashRod wants to merge 1 commit into
Open
feat(ipc): add per-client tag event to zdwl_ipc_output_v2 v3#887dashdashRod wants to merge 1 commit into
dashdashRod wants to merge 1 commit into
Conversation
Adds `client` event reporting appid/title/tagmask once per managed client per output during state-update batches. Closes the gap where consumers could see per-tag client counts but not per-tag client identities. Bumps zdwl_ipc_output_v2 interface to v3 and zdwl_ipc_manager_v2 global advertisement to v3. Implementation localized to dwl_ipc_output_printstatus_to in src/ext-protocol/dwl-ipc.h.
Collaborator
|
This dwl ipc protocol is planned to be abandoned and I have no intention of changing it again |
That's probably good, but this is basically just a version bump temporary |
zzonez
pushed a commit
to zzonez/mango
that referenced
this pull request
May 11, 2026
Adds `client` event reporting appid/title/tagmask once per managed client per output during state-update batches. Closes the gap where consumers could see per-tag client counts but not per-tag client identities. Bumps zdwl_ipc_output_v2 interface to v3 and zdwl_ipc_manager_v2 global advertisement to v3. Implementation localized to dwl_ipc_output_printstatus_to in src/ext-protocol/dwl-ipc.h. fix(ipc): correct opcode order, frame placement, and add stable client id Three issues with the original PR mangowm#887 commit: 1. The new `client` event was inserted between `appid` and `layout_symbol` in the XML, which shifts opcodes for every event after it and breaks wire compatibility with v2 consumers. Wayland convention is to append new events at the end of the interface. Moved `client` to the end under a `<!-- Version 3 -->` marker. 2. `zdwl_ipc_output_v2_send_frame()` was called before the per-client emit loop, but `frame` is documented as the end-of-batch marker ("the update sequence is done"). Consumers that rely on it to commit a fresh window list per output would see stale data. Moved the loop above the frame send. 3. The event carried only appid/title/tagmask, which can't distinguish two windows with identical metadata. Added a `uint id` field, sourced from a new monotonic `Client.ipc_id` assigned at creation (skipping 0 so consumers can treat 0 as "unset"). This pairs with the focusclient_byid dispatch in a follow-up commit. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposal: per-client tag identification via new
clientevent in zdwl_ipc_output_v2The gap
Mango's IPC currently exposes per-tag client counts via the existing
tageventon
zdwl_ipc_output_v2, but no way to associate clients with their tags.zwlr_foreign_toplevel_manager_v1reports all toplevels with their appid/titlebut no tag information;
ext_workspace_manager_v1reports tag state but notoplevel association. The two streams are disjoint, so consumers (status bars,
custom launchers, scripted layouts) can know "tag 3 has 2 windows" or
"these toplevels exist," but not "which windows are on tag 3."
The information exists internally — every
Clientstruct has atagsbitmask —it just isn't exposed.
Reproduction
Diagnostic client binding both protocols against an unmodified mango:
Tag 1 active, three windows open across multiple tags:
Tag 4 active, same three windows:
The toplevel list is identical. There's no way for a consumer to determine which
window lives on which tag. The output came via mtags,
a small Wayland test client that connects to the compositor, binds the available
workspace/toplevel/dwl-ipc protocols, listens for events, and prints workspace, window,
and tag/client state for debugging.
Proposal
Add a
clientevent tozdwl_ipc_output_v2(bumped to interface version 3)that fires once per managed client per output during the existing state-update
batch, after the per-tag events and before
frame:Verification
Working prototype on the fork. Same diagnostic client, this time bound to
zdwl_ipc_manager_v2 v3. Two foot terminals on tag 1:Implementation is localized, one event definition in the XML, one loop in
dwl_ipc_output_printstatus_to, plus the version bump where the global iscreated. Checkout the diff in this fork fork
After moving one to tag 4 via
mmsg -d tag,4:Bitmask correlates correctly with tag membership (0x1 = tag 1, 0x8 = tag 4).
Full mtags output
Notes
The event reports
appid/title/tagmask. More fields (pid, floating/fullscreen, monitor) can be added later — Wayland version bumps are backward-compatible, so older clients just ignore newer events.