fix(sender): make receiver names readable on the unselected row card - #35
Merged
Conversation
The receiver rows paint a hardcoded dark card — `from_gray(30)` when unselected, a dark blue when selected — but the name label carried no explicit colour, so it inherited the theme's default text colour. eframe follows the system theme and nothing in the app overrides it, so on a Mac in light mode the default is near-black: near-black text on a near-black card, effectively invisible. The selected row escaped only because mid blue gives dark text more contrast than near-black does, which is why the bug reads as "only the unselected ones are broken". Pair the fill and the text colour in one binding so the two cannot drift apart again, and set the name explicitly to white on the selected card and gray(235) on the unselected one. The subtitle already sets its own colour (GRAY on gray(30) is about 6.5:1) and is left alone. This fixes the contrast on the fixed-dark cards; it does not address the wider point that the rest of the window follows the system theme while these cards do not.
snadahalli
force-pushed
the
fix/receiver-row-contrast
branch
from
August 26, 2026 09:38
3d1b6ec to
5f6ebd8
Compare
Developer1010x
pushed a commit
that referenced
this pull request
Aug 26, 2026
…43) #42 was merged twelve seconds after #41, into `fix/airplay-hkp-header` — which #41 had just merged into master and left behind. The merge succeeded, so nothing looked wrong, but the commits landed on a branch nothing points at and master never received them. Master therefore has the `X-Apple-HKP` header from #41 and none of what it was a prerequisite for: the SRP proof still hashes g padded, transient pairing still runs M5/M6 and gets the connection closed, and there is no encrypted control channel. Pairing is broken on master in exactly the way #42 fixed. This restores #42's own diff — the eight `openplay-airplay` files it actually touched — on top of current master. Deliberately *not* a merge of `fix/airplay-hkp-header`. That branch was cut before #35, #36, #37, #39 and #40 merged, so a diff against it reads as deleting `openplay-discovery/src/address.rs` and reverting 244 lines of `openplay-sender/src/app.rs`. Merging it would silently undo five landed fixes. Only the range between #42 and its own parent is safe to replay, and that range touches nothing outside `openplay-airplay`. Verified after the replay: 233 tests pass, clippy and fmt clean, and the work from #35/#36/#37/#40 is still in the tree. Co-authored-by: Sandeepa Nadahalli <1698507+snadahalli@users.noreply.github.com>
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
2 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.
The bug
Receiver names are effectively invisible on unselected rows when the app runs in light mode.
The rows paint a hardcoded dark card —
Color32::from_gray(30)when unselected, a dark blue when selected — but the name label carried no explicit colour, so it inherited the theme's default text colour. eframe follows the system theme and nothing in the app overrides it, so on a Mac in light mode that default is near-black. Near-black text on a near-black card.The selected row escaped only because mid blue gives dark text more contrast than near-black does, which is why the bug presents as "only the unselected ones are broken" rather than as an obviously global problem.
The fix
Pair the fill and the text colour in a single binding so the two cannot drift apart again, and set the name explicitly: white on the selected card,
gray(235)on the unselected one.The subtitle already sets its own colour and is left alone —
GRAYongray(30)is roughly 6.5:1, comfortably past the 4.5:1 needed at that size.What this does not fix
The rest of the window follows the system theme while these cards are hardcoded dark, which is why the app reads as half-light/half-dark. Making the cards theme-aware is a design decision rather than a contrast fix, so it is left alone here.
Verified locally on macOS arm64:
fmt --checkclean,clippy -D warningsclean, and the sender runs and lists receivers without errors.