[switcher] transparency makes it hard to distinguish the windows against the wallpaper
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
Research direction
Start at the switcher plugin and reproduce the issue with multiple windows using the Super + Tab cycling entry point. Trace how the centered window's transparency is updated after cycling begins. Done means the currently focused or centered window remains fully opaque throughout the switcher cycle, while the reproduction steps no longer show all windows as transparent.
Written by the indexing model from the issue text.
Description
Wayfire: 0.12.0-71f2bcfa (Sep 26 2026) branch master wlroots-0.20.2
When invoking the switcher plugin, the initial view correctly shows the currently active window as opaque while inactive windows have transparency. However, as soon as the user starts cycling through the windows, the transparency state fails to update dynamically for the newly centered/active window—causing all windows in the cycle view (including the currently selected one) to remain transparent. This severely degrades readability against dynamic wallpapers.
To Reproduce
Enable the switcher plugin.
Open multiple windows.
Trigger the switcher (e.g., Super + Tab). Notice the initially active window is opaque.
Begin cycling through the window list.
Observation: The currently centered/active window loses its full opacity and renders with transparency while cycling.
Expected behavior
The currently focused/centered window in the switcher should always remain fully opaque (1.0 alpha) during the entire cycling process, allowing the user to easily distinguish the active selection from the background stack, similar to how standard window switchers behave.
Additional context
Wayfire version: 0.12.0 (built from source)
Operating System: Fedora 44 (Rawhide)
- Dominant language
- C++
- Stars
- 3.1k
- Forks
- 246
- Avg merge
- 3d 21h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WayfireWM/wayfire
-
CI: style check will fail once ubuntu-latest moves to Ubuntu 26.04 (CMake 4)Possibly taken @italopaesano claimed this 9 days ago. Open
Difficulty 2/5 Under an hour Newbie friendliness 72/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
WayfireWM/wayfire#3148 · 1 comment ·
Maintainers usually reply within 3 days
-
easy enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WayfireWM/wayfire#3005 · 14 comments ·
Maintainers usually reply within 3 days
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 3 days
-
[move/grid] Window manipulation by dragging titlebar with touch doesn't work in some casesPossibly taken @mi4code claimed this 1 day ago. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 52/100
Maintainers usually reply within 3 days
All issues in WayfireWM/wayfire
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
foxglove/mcap#1907 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
telegramdesktop/tdesktop#31505 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
ll-builder shell completions omit existing lockfile commands and --lockedPossibly taken @project-nju-learner claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
OpenAtom-Linyaps/linyaps#2291 ·
Maintainers usually reply within 1 day