feat(settings): adjustable window opacity, and end the Wayland opacity-warning spam#5
Open
Zakkaus wants to merge 9 commits into
Open
feat(settings): adjustable window opacity, and end the Wayland opacity-warning spam#5Zakkaus wants to merge 9 commits into
Zakkaus wants to merge 9 commits into
Conversation
Add a "Window opacity" control (General tab) for the settings window itself — the lyrics overlay already had its own opacity, but the settings dialog was always solid. Applied via setWindowOpacity on open, live while dragging, and committed on Apply. Default 96% (a touch see-through, text stays fully legible); clamped 60–100%. Works on KWin; harmless where the platform ignores window opacity.
…a no-op on Wayland) The Qt Wayland plugin has no client-side window-opacity protocol, so setWindowOpacity just logged "This plugin does not support setting window opacity" and did nothing. Drive the see-through level through the painted window fill (paintEvent alpha) and the light-theme card alpha instead — the same way the overlay panel's opacity already works — so it takes effect under KWin. Live preview re-skins + repaints on change. Also drop the overlay's redundant setWindowOpacity(1.0) that produced the same warning at startup.
Kotonoha maps no normal top-level window (only a tray icon + a Wayland layer-shell overlay), so the launcher's startup notification never completes and KDE shows the 'launching' feedback until it times out. Opt out of startup notification.
Zakkaus
changed the title
- 100% now paints a fully solid window (alpha 255). It looked see-through before because the mapping scaled the palette's window fill, whose base alpha is 240, so the max still read as ~94% opaque. - Range is the full 0-100% (was 60-100), default lowered to 90%.
The real source of the repeated 'This plugin does not support setting window opacity' spam: the settings dialog's fade-in animates the windowOpacity property, firing setWindowOpacity ~once per frame. Qt's Wayland plugin ignores it (so there was no fade anyway) and warns each time. Only run the fade where window opacity is actually supported (X11); Wayland now shows the window instantly and silently.
Zakkaus
changed the title
- setKeyboardTracking(False) on the opacity spin box so typing e.g. "95" no longer flashes the window near-invisible as it passes through the digit "9". Spin arrows still preview live. - Default opacity 90% -> 95%.
The opacity was the only setting that previewed live, and that live preview flashed the window near-invisible while typing (e.g. "95" passing through "9"). Drop the live preview entirely so it commits on the existing OK/Apply buttons like every other setting — no flashing, and consistent behaviour.
Zakkaus
changed the title
…w the note The frosted-glass window only works on KDE Wayland. Off it, the checkbox is now disabled (dimmed label + muted, non-accent box via new :disabled QSS) so it reads as unavailable instead of an option that silently does nothing, and the KDE-only hint is always shown under it (previously only when blur was unavailable).
On KDE (Breeze) / Fusion the combo style opens a native, system-palette popup that ignores the dark item-view QSS, so the Theme/Language/etc. dropdowns rendered white on the dark settings window. combobox-popup: 0 forces the styled drop-down list, so the popup follows the app theme. (Offscreen already used the list view, hence it looked fine in headless renders.)
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
1 participant
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.
Summary
Adds a Window opacity control for the settings window, removes the repeated
This plugin does not support setting window opacitywarnings on KDE Wayland, and stops KDE bouncing the launcher at startup.Window opacity
config.settings_opacity— a spin box over the full 0–100%, default 95% (a touch see-through; text stays fully legible). Covered by "Reset tab" and translated across en / zh-Hans / zh-Hant / ja.paintEvent, plus the light theme's card — notsetWindowOpacity, which Qt's Wayland plugin ignores (no client-side opacity protocol). So it works under KWin, and 100% is genuinely opaque (alpha 255; before, the max scaled the palette's 240 fill and still read ~94% see-through). This is separate from the Frosted-glass (KWin blur) toggle and works on any compositor, not just KDE.Ending the
setWindowOpacitywarningThe
This plugin does not support setting window opacityspam had three sources, all removed/guarded:setWindowOpacity(1.0)at startup,setWindowOpacitycalls (replaced by painted alpha),windowOpacityproperty (~onesetWindowOpacityper frame). It's now skipped on Wayland — where it never faded anyway — so the window just appears, silently. (Still fades on X11, where the property works.)Startup
StartupNotify=falseinkotonoha.desktop: the app maps no normal top-level window (a tray icon + a layer-shell overlay only), so the launcher's startup notification never completed and KDE bounced the "launching" feedback until it timed out.Fallback behaviour
Frosted glass stays gated to KDE Wayland (
_blur_capable = blur.available and wayland and KDE); everywhere else_frostedisFalseand the window paints a normal solid panel. Off KDE the Frosted-glass checkbox is disabled (greyed out) with an always-visible KDE-only note, so it reads as unavailable rather than an option that silently does nothing. The painted-alpha window opacity works regardless. Covered bytest_frost_only_on_kwin_wayland_and_blur_lifecycle_is_safeandtest_frost_checkbox_is_greyed_out_and_noted_when_blur_unavailable.Testing
pytest352 passed (3 new: config clamp/default, OK/Apply round-trip, and a render check that 100% is fully opaque while a lower value is clearly see-through). ruff/ty clean.