## New version 57. What changed in this update... This update fixes three things in the alarm and preview-font logic. No new features, no new settings, no UI changes. ### 1. Alarm could be missed after the computer wakes from sleep Before: the extension checked the current time every second and compared it to the alarm time. If the computer was suspended exactly during that minute, the check never ran, so the alarm never fired that day. Now: the extension also compares the alarm time against the last time it checked. If the target time falls between the last check and now, it fires the alarm. This covers the case where the system was asleep right through the alarm time and only wakes up afterward. ### 2. Preview font in the settings window was never updated after install The settings window installs a copy of the font in the user's local fonts folder so the live preview looks right. Before, this copy was only made once — if a future version of the extension shipped an updated font file, the old copy on disk would stay forever, since the code only checked "does the file exist," not "is it the current one." Now it compares file size and modification date between the bundled font and the installed copy, and only re-copies when they differ. Same install location, same trigger point (opening preferences), just correct on updates. ### 3. Alarm sound depended on GStreamer, and later had a silent-failure issue The alarm used to call `Gst.init()` and build a full `playbin` pipeline just to play a short `.ogg` file. This pulled in a GStreamer dependency for something very small. First pass: switched to `global.display.get_sound_player()`, the sound player built into GNOME Shell / Mutter. This removed the GStreamer dependency, but testing showed it produced no audio at all on at least one system. That API is an optional Mutter feature (`-Dsound_player`) that some distros build without, and it fails silently when unavailable — no exception, no sound. Final approach: the extension now plays the alarm sound by spawning a system audio player (`paplay`, falling back to `pw-play`, then `aplay`) via `Gio.Subprocess`. This is the same approach used by several other alarm/timer extensions, doesn't require GStreamer, and doesn't depend on an optional Mutter build flag. The bundled alarm sound was also converted from `.ogg` to `.wav`, since `aplay` (the last fallback in the chain) only supports WAV — this keeps all three fallback players reliably compatible with the bundled file. Stopping the alarm now also kills the sound process immediately (`force_exit()`), instead of waiting for a GStreamer pipeline teardown. ## Files touched - `extension.js` - `prefs.js` - `assets/alarm.wav` (replaces `assets/alarm.ogg`) - `README.md` (file listing updated to match the new asset name) ## Testing Manually tested on GNOME Shell, both the panel and desktop-widget modes, with the alarm enabled and the message/time settings changed. Confirmed the alarm sound plays and stops correctly, and that the extension still enables/disables cleanly with no leftover timeouts or processes (checked via `journalctl` and Looking Glass). Thanks for the great job and time :)

You shouldn't actually use spawn command to play the sound since it can be done with gjs but what do you mean the `global.display.get_sound_player()` has no sound at all? GNOME Shell actually playing the sound the same way: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/5a7d1417b91662ea6532ab326657f528c2e0bf7a/js/ui/screenshot.js#L2810-2812

Thanks for the reference, that's helpful. You're right that global.display.get_sound_player() is the correct way to do this, and I agree it shouldn't be replaced with a spawned process. When I tested play_from_file() earlier I got no audio on my test machine, but in hindsight that was most likely a muted per-app volume stream for "GNOME Shell" in PipeWire/PulseAudio on that system, not a limitation of the API itself. The sound plays as part of the gnome-shell process itself, so if that stream happens to be muted, it fails silently with no exception, which is exactly what I saw. Spawning an external player created a separate, unmuted stream, which is why that "worked." I'll switch back to global.display.get_sound_player().play_from_file() and drop the subprocess approach. Will test again and resubmit.

Thanks for the reference, that's helpful. You're right that global.display.get_sound_player() is the correct way to do this, and I agree it shouldn't be replaced with a spawned process. When I tested play_from_file() earlier I got no audio on my test machine, but in hindsight that was most likely a muted per-app volume stream for "GNOME Shell" in PipeWire/PulseAudio on that system, not a limitation of the API itself. The sound plays as part of the gnome-shell process itself, so if that stream happens to be muted, it fails silently with no exception, which is exactly what I saw. Spawning an external player created a separate, unmuted stream, which is why that "worked." I'll switch back to global.display.get_sound_player().play_from_file() and drop the subprocess approach. Will test again and resubmit.

Can I send just extension.js, or should I send the zip with version 58?

Let's stick with the Ogg file for the time being while I investigate further

Auto-rejected because of new version 58 was uploaded