GNOME Bugzilla – Bug 735869
Keep application alive to ring alarms&timers
Last modified: 2020-11-24 11:59:27 UTC
We have been waiting for GNotification to grow support for scheduled notifications, but this still seems far, so I think it is time we start handling alarms etc on our own: not ringing an alarm if you close the app is pretty lame. I think we can do an hack like this in application::startup() + // If we are launched as a service (which should be the case + // most of the time), grab an extra reference so that we stay + // around to make alarms and timer ring even if the window is + // closed. We should revisit this if GNotification adds a way + // to schedule a notification at a given time in the future + if ((get_flags () & ApplicationFlags.IS_SERVICE) != 0) { + hold (); + } but before going further, I'd like to check with Ryan if this is legit or if it is a bad idea... If we go that way, we would still need to change more things to make things work: 1) refactor AlarmFace and TimerFace to split out AlarmMovement and TimerMovement classes: the Movement classes should be owned by the App and not be disposed when the window is closed 2) optionally add a --stop-service command line option to cleanly release the extra ref 3) consider adding clocks to autostart and maybe add logic to exit if there are no pending alarms and timers
This is blocking on proper time-based activation support from systemd and on systemd-in-the-session... The idea is that clocks would normally _not_ be running but it would instead tell systemd about when it needs to be woken (in order to fire the alarm event). It would also tell systemd to wake it in case of things like timezone changes which might impact which is the next alarm.
(In reply to comment #1) > This is blocking on proper time-based activation support from systemd and on > systemd-in-the-session... > Sure,as mentioned at the start of the report I agree that's the "right" way... What I am wondering if the idea described in comment #1 as a stop-gap solution would be ok or if calling app.hold() in that way would be problematic
I only find the service check to be suspicious.... btw: this bug has nothing to do with GNotification :)
(In reply to comment #3) > I only find the service check to be suspicious.... > The idea was to hold the app when lauched through gnome-shell etc, but not hold it when lauched from a terminal > btw: this bug has nothing to do with GNotification :) True, it is just that "wake application app at some point in the future" was discussed as part of that and it stuck in my mind
How about having a "time service" that provides an API to all applications? Since we are trying to go towards sandboxing this would make totally sense for me. Use cases: * Contacts e.g. could request the time of a location to display (reverse thing from what's requested in bug #698832) * Clocks can be fully closed, obviously * Other apps could set up alarms (maybe one could provide some datetime service that is useful for calendars too)
I agree -- I even hacked up an example of such a service that could have been rolled in gnome-session but I didn't commit it since for several cycles now, systemd-in-the-session is coming next cycle...
(In reply to comment #6) > I agree -- I even hacked up an example of such a service that could have been > rolled in gnome-session but I didn't commit it since for several cycles now, > systemd-in-the-session is coming next cycle... Let me know if I can help.
Would also be nice to tage bug #686115 into account. This way you'd actually be able to use your PC to wake you up.
*** Bug 689082 has been marked as a duplicate of this bug. ***
Just an idea... You already need a service to keep dateMenu (the clock in gnome-shell) updated. Therefore, I would assume, that this very same service can take handle of timed notifications (such as alarms).
*** Bug 772819 has been marked as a duplicate of this bug. ***
*** Bug 772820 has been marked as a duplicate of this bug. ***
This bug is ugly enough that I think the Alarm tab needs to be disabled until this bug is fixed. People need to have more pride in their work than allowing this sort of bug to stick around for 3 years. Yank the feature until the feature works properly. Offhand I can't tell you whether macOS has any such feature, but if it does, I know it works. This is a trust damaging bug. Fix it, or remote the element entirely and ceded this function to a 3rd party (presumably setting an alarm in the calendar application will provide notifications, but I haven't tried it). Thanks.
This bug is the reason GNOME Clocks is not installed out-of-the-box in Ubuntu: https://lists.ubuntu.com/archives/ubuntu-desktop/2017-August/005092.html
(In reply to Michael Catanzaro from comment #14) > This bug is the reason GNOME Clocks is not installed out-of-the-box in > Ubuntu: > > https://lists.ubuntu.com/archives/ubuntu-desktop/2017-August/005092.html Since I started working on the systemd --user stuff (bug #690866), and we would like to have this in Ubuntu, I'll take a look at this bug. I suppose it'll depend on that one. If we go the timer unit route, any ideas how to handle timezone changes? AFAICS timer units will fire at their original (absolute) time across timezone changes. e.g: laney@nightingale> timedatectl set-timezone Europe/London laney@nightingale> date Thu 18 Jan 17:30:15 GMT 2018 laney@nightingale> systemd-run --on-calendar="2018-01-18 18:00" --user true Running timer as unit: run-rf5fd6c7166ea48039aa517187cb4ec2c.timer Will run service as unit: run-rf5fd6c7166ea48039aa517187cb4ec2c.service laney@nightingale> systemctl --user list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2018-01-18 18:00:00 GMT 29min left n/a n/a run-rf5fd6c7166ea48039aa517187cb4ec2c.timer run-rf5fd6c7166ea48039aa517187cb4ec2c.service 1 timer listed. Pass --all to see loaded but inactive timers, too. laney@nightingale> timedatectl set-timezone Europe/Paris laney@nightingale> systemctl --user list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2018-01-18 19:00:00 CET 29min left n/a n/a run-rf5fd6c7166ea48039aa517187cb4ec2c.timer run-rf5fd6c7166ea48039aa517187cb4ec2c.service 1 timer listed. ...I think the current & expected behaviour is to fire at the 'local' time? So when I changed timezone then, the alarm should have fired immediately, and if I went west then it should have had time added.
I'd expect timers to be in a global always moving forward timeline, so changing timezones would have no effect. And for alarms: (In reply to Iain Lane from comment #15) <snip> > ...I think the current & expected behaviour is to fire at the 'local' time? > So when I changed timezone then, the alarm should have fired immediately, > and if I went west then it should have had time added. I'd expect an alarm to be triggered the next time it's that time in the local timezone. For example, you have an alarm for 7:30 in the morning and it's 8:00 in your continental Europe (GMT+1) timezone. Switching it to UK/GMT time means it'll trigger in 30 minutes (it'll be 7:00, your alarm is for 7:30). Conversely, it's 7:00 in your UK timezone, you have an alarm for 7:30, you switch to GMT+1 timezone, the alarm will only trigger tomorrow. (I should note that this is the behaviour I'd expect for Clocks, not for appointment alarms). I think filing a bug against systemd for this feature might be a good idea, as there are likely other uses to this sort of timezone-aware timers. More so in the session than at the system level (backups, alarms, housekeeping in general, parental controls/lockdown, etc.).
> I think filing a bug against systemd for this feature might be a good idea, as there are likely other uses to this sort of timezone-aware timers. Although I’m pro-systemd, and I think this is generally a good idea, making Clocks depend on systemd in this specific task sounds bad to me. I understand that the platform where GNOME is installed on is Linux, this would rule out other platforms to use Clocks in a sensible way.
Superseded by https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/1