* fix(doctor): validate QT_QPA_PLATFORMTHEME instead of trusting its presence
dms doctor reported any non-empty QT_QPA_PLATFORMTHEME as healthy, so a
wrong value passed with "All checks passed!" while every Qt app silently
ran without a platform theme: palettes stayed unstyled and QIcon lookups
returned nothing, which is how Quickshell ends up drawing its missing-
icon placeholder for every icon an SNI app such as blueman publishes in
tray menus. The real-world trap is qt6ct-kde — the AUR package name —
set as the theme value; the settings UI toast already documents that
only the qt6ct theme requires the qt6ct-kde package, but the doctor,
the tool meant to catch exactly this, blessed the broken value.
- checkQtPlatformThemePlugin validates both QT_QPA_PLATFORMTHEME and
QT_QPA_PLATFORMTHEME_QT6 (the latter was not reported at all):
qt6ct-kde gets a targeted warning naming the fix, and any other value
has its plugin probed the way the qtengine check does — qmake/qtpaths
are asked for QT_INSTALL_PLUGINS and the conventional file names are
looked up, warning with the exact expected path on a miss
- a miss never warns when it cannot be sure: no Qt build tools and the
version-dependent plasma-integration file name both degrade to info,
mirroring the qtengine check's no-false-alarm policy
- the plugin-root interrogation moves into qtPluginRoots, shared with
the qtengine check
On an affected system:
before: ○ QT_QPA_PLATFORMTHEME · qt6ct-kde
✓ All checks passed!
after: ○ QT_QPA_PLATFORMTHEME · qt6ct-kde
● qt6ct-kde Package name, not a theme
* fix(doctor): probe qtengine plugin with a bare file name
qtenginePluginFile("", major) returns a path with a directory
component, and qtPluginPath joins platformthemes/ again, so the
qtengine check stat'd
<root>/platformthemes/platformthemes/libqt6engine-plugin.so and warned
"Not found" on every correctly installed system. Pass the bare file
name instead, and pin the resolved path with a regression test that
fails on the double join.
Found in review by claude[bot].
* Update core/cmd/dms/commands_doctor.go
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
* fix(theme): take sun times from the local calendar day, not the UTC one
CalculateSunTimesWithTwilight read its reference day off date.UTC(). The
event seconds it computes are local mean solar time and lonOffset converts
them to UTC, so the instant of a local day's sunrise lands on the previous
UTC day east of Greenwich and a local sunset on the next one west of it.
Whenever the local and UTC calendars disagree, the function therefore
returned a neighbouring day's times.
Everything around it already works in local calendar days: the polar
branches of CalculateSunTimes build their day from date.Year/Month/Day,
thememode's startOfNextDay uses next.Location(), and the gamma scheduler
keys its calcDay cache on now.Location(). Only the reference day inside
the calculation disagreed.
Effect at UTC+8 (Kunming, 25.04N 102.72E): between local sunrise and 08:00
local, computeLocationSchedule got yesterday's sunrise and sunset, both
already past, fell through to the next-day branch and got today's sunrise,
also past. It reported dark with nextTransition in the past, which
schedulerLoop clamps to a one-second wait, so it re-evaluated every second
until 08:00 local and then flipped to light on its own. West of UTC the
mirror image: at UTC-7 the mode went dark from 17:00 local, when the UTC
date rolls over, until the real sunset.
The same SunTimes drive the gamma/night-light scheduler, so night light
shifted by a day the same way.
Fix: derive the reference day from date's own calendar day, keeping
dayStart anchored at UTC midnight so the lonOffset arithmetic is
unchanged, and take the orbit angle from the same day. Callers whose date
is already in UTC are unaffected.
Tests: suncalc_refday_test.go covers the reference day east and west of
UTC, stability across UTC midnight, and that UTC callers do not move.
manager_location_test.go is new to the thememode package and covers
computeLocationSchedule at both offsets, including that nextTransition is
never in the past.
* fix(theme): pick the reference day from the solar day, not the civil one
Taking the reference day straight off the caller's calendar day is right
for nearly every zone, but not for one shifted a full day away from its
own meridian. Apia, Kiritimati, Tongatapu and the Chathams all sit on
west longitudes while keeping a UTC+12:45..+14 offset, so their mean
solar time and their civil time are a day apart. Every sun event landed
on the following local day there, and the location schedule reported
dark around the clock.
Anchor on the caller's local noon and convert that to mean solar time to
pick the reference day. For every other zone this resolves to the same
date as before, so Kunming, Los Angeles and London are unchanged to the
second. dateOrbitAngle now takes the same reference day, so declination
and the equation of time no longer belong to a different day than the
events computed from them.
Covered at both levels: three antimeridian zones in the suncalc test,
and two cases in the location schedule test for the symptom itself.
Both fail without this change.
In Hyprland a second bind on an already bound key does not replace the
first, both stay live, which is why an override is written as hl.unbind
followed by hl.bind. The parser dropped that pair on the floor when it
came from a user's own Lua module:
- parseLuaLines discarded the unbind whenever the same file rebound the
key, so the DMS default was never removed
- addBind then treated the rebind as a config bind conflicting with a DMS
bind, counted it in bindsAfterDMS and returned false, so it never
reached the section
The keybinds modal therefore showed the DMS default for that key and the
user's actual action was nowhere, which is what #3145 reports.
The discard existed to protect dms/binds-user.lua, the file the settings
modal writes, which uses the same unbind+bind pair: recording its unbind
would have deleted its own rebind too, since that file is also a DMS bind
source. The guard was just too coarse, suppressing the unbind entirely
instead of exempting the one bind it belongs to.
Now the unbind is always recorded, and rebindSources remembers which file
unbound and rebound a key so removeUnboundDMSBinds spares that file's own
bind. addBind treats a bind as an override, not a conflict, when the same
file unbound the key earlier — tracked per file in fileUnbinds, saved and
restored around each parsed file so an include cannot leak into its
parent.
A config bind without a preceding unbind is unchanged: both binds really
are live in Hyprland, so it stays a conflict and keeps counting towards
"Some DMS binds may be overridden by config binds".
No other provider has an unbind concept; mangowc, niri and sway parse
formats without one, so this is Hyprland-only.
Tests: hyprland_parser_override_test.go covers the reported case, the
conflict case without an unbind, a bare unbind with no rebind, and the
dms/binds-user.lua round trip. Only the first fails without the fix; the
other three pass either way and guard against over-correcting.
* feat(clipboard): clear only the filtered entries
With a search query or type filter active, the clear button deleted
every unpinned entry regardless of what the list was showing, so
pruning a subset meant deleting entries one by one from the context
menu.
When the recents list is filtered, the button now clears exactly the
entries it shows and the modal stays open on that filter; with no
filter the previous behaviour is untouched. A filter that matches
nothing does nothing at all, rather than falling back to clearing
everything. The tooltip says "Clear Filtered" while a filter is
active, and the confirmation names the count.
Deleting one id at a time would have cost a round trip and a full
state broadcast per entry, so this adds clipboard.deleteEntries: one
bolt transaction, one state update, and it skips pinned entries
server-side so a bulk delete can never take out saved items.
Fixes#3198
* fix(clipboard): add translator context and list deleteEntries in IPC help
Review follow-up.
The two strings this branch adds carried no translator context: the
"Clear Filtered" tooltip in ClipboardHeader and the confirmation body for
a filtered clear in ClipboardHistoryContent. Both now say where they
appear, and the second one names what %1 is, per CONTRIBUTING.
"Clear All" on the same line is deliberately left alone. It is an
existing shared term with four other call sites, so a context there would
attach a clipboard-specific comment to a term the printer tab also uses.
clipboard.deleteEntries was handled but absent from the IPC method
listing that `dms debug-srv` prints, which left it undiscoverable right
next to clipboard.deleteEntry.
Catalogs untouched.
* chore: re-trigger CI
The lint-and-test failure on 21cefbf is an unrelated flake:
TestStoreEntry_CorruptDBReturnsErrorNotPanic died with SIGBUS in the
bbolt mmap. That test comes from master (c68b7e5) and passes there;
this branch only adds TestDeleteEntries_*/TestHandleDeleteEntries_*
and touches manager.go additively.
* clipboard: survive mmap faults from corrupted db pages
---------
Co-authored-by: bbedward <[email protected]>
The battery popout already surfaces the UPower energy rate, but the bar
widget could only show percentage and remaining time, so telling how fast
the battery is charging or draining meant opening the popout (or running a
third-party plugin that polls /sys/class/power_supply).
Add two independent, opt-in toggles to the battery widget - "Show Charge
Rate" and "Show Discharge Rate" - that render the signed rate next to the
existing text, e.g. "+28W" while charging and "77% (2h 11m) -19W" while
draining. Both default to off, and follow the established pattern: a global
default in SettingsData plus a per-widget-instance override.
The value comes from BatteryService.changeRate, so there is no extra process
or polling. It hides itself when the rate is below 0.05W (idle, fully
charged, or sitting at a charge limit) so it costs no bar space unless it
has something to say. Precision adapts to keep the pill narrow: one decimal
below 10W, whole watts above; vertical bars get a whole-watt line.
* fix(dock): hide overlay dock over fullscreen
* fix(dock): track fullscreen state declaratively
* fix(dock): clear overlay mask during fullscreen
* feat(dock): add fullscreen visibility option
* fix(dock): preserve auto-hide fullscreen behavior
* fix(dock): keep fullscreen mask interactive in overview
* fix(frame): host dock on overview without show dock
* feat(mpris): pin preferred media source
Add a minimal "pin media source" option so the bar media widget and OSD
keep showing a preferred player (e.g. a music player) even when another
source (e.g. YouTube in the browser) starts playing.
- MprisController: new pinnedIdentity property + setPinned(identity);
_bestPlayingPlayer() prefers a playing pinned player (exact identity
match, then case-insensitive substring fallback). Existing behavior
is unchanged when no pin is set.
- Persistence via SessionData.pinnedPlayerIdentity (spec entry added so
SessionData.set() accepts the key); empty string clears the pin.
- MediaDropdownOverlay (Media Players panel): each player row gets a
theme-colored circle indicator on the right. Empty circle = no pin
(initial state). Right-click a row to make it the default source
(circle fills); right-click another row to move the pin; right-click
the pinned row again to clear (back to empty). Left-click behavior
unchanged (selects the player).
* Update quickshell/Services/MprisController.qml
Concur with Claude's suggestion.
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
* Update quickshell/Services/MprisController.qml
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
CompositorService detects the compositor asynchronously: compositorInitTimer
waits 100ms before calling detectCompositor(), which shells out to identify
the Wayland socket owner and only sets the compositor flags in its callback.
KeyboardLayoutName gates its initial updateLayout() on CompositorService.isHyprland
in Component.onCompleted, which always runs before that lands, so the call never
happens and the widget renders with an empty label until the first activelayout
event, i.e. until the user switches layout by hand.
Re-run updateLayout() when the detected compositor changes. updateLayout()
already branches on the compositor internally, so one handler covers every
backend.
Co-authored-by: shalevc1098 <[email protected]>
* feat: add cellular support
* fix(settings): resolve cellular tab index collision
* fix: address review feedback for cellular support
Bump the network API version, drop the deleted term freeze file,
regenerate the settings search index, and reuse existing translation
terms where they already cover the new cellular UI.
* fix: do not assign readonly userPreference when switching network type
Assigning SettingsData.networkPreference through the readonly alias
threw on click, so the Cellular segment in Control Center did nothing.
* fix: make Cellular selectable and the modem row clickable
The Control Center type switcher was bound only to preference, so
Cellular snapped back to Ethernet. The settings modem row highlighted
on hover but had no click handler. Show the modem as a connect target
when no APN profiles exist.
* fix: create a GSM profile when connecting cellular with none saved
Clicking Mobile broadband only activated an existing profile, so a
modem with no APN did nothing useful. Fall back to AddAndActivate
like ethernet connect.
* fix: address second round of cellular review feedback
- Guard cellularDevices map with devMutex via snapshot/by-iface/set/remove
helpers, mirroring the existing ethernet and wifi accessors
- Regenerate mocks with mockery v3 instead of hand-editing mock_Backend.go
- Reuse refreshCellularState() in SetCellularEnabled, DisconnectCellular,
DisconnectCellularDevice, ActivateCellularConnection and device removal
- Wrap retryErr rather than the first error when the auto-config retry fails
- Use Theme.surfaceTextSecondary/primaryHover/primaryHoverLight in the
cellular-off state instead of hand-rolled Qt.rgba values
- Drop the duplicate "No devices found" label so it can no longer render
twice with no modem and no saved config
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
* fix: address remaining cellular review comments
- Toast "Failed to toggle cellular" instead of always "enable"
- Remove unused enableCellularRadio() wrappers
- Store Control Center network type as a value, not a list index
* fix: pass nmcli connection selector as separate argument
`nmcli con mod uuid:<UUID>` is not valid syntax -- nmcli expects the
selector keyword as its own argument, so every priority update failed
with "no such connection profile". Because practically every NM profile
has a UUID, this silently disabled autoconnect-priority and route-metric
updates for ethernet and WiFi as well as cellular.
Also fix the Cellular settings status text, which said "Connecting..."
for a flag that only tracks radio enable/disable, and add the seven
cellular terms that were missing from the translation catalogs.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
* apply review comments
* fix lints
* update debug doc
* fix style inconsistencies
---------
Co-authored-by: Yechiel Worenklein <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Co-authored-by: bbedward <[email protected]>
bbedward