After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735869 - Keep application alive to ring alarms&timers
Keep application alive to ring alarms&timers
Status: RESOLVED OBSOLETE
Product: gnome-clocks
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Clocks maintainer(s)
Clocks maintainer(s)
: 689082 772819 772820 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-09-02 07:42 UTC by Paolo Borelli
Modified: 2020-11-24 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paolo Borelli 2014-09-02 07:42:25 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
Comment 1 Allison Karlitskaya (desrt) 2014-09-03 16:46:47 UTC
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.
Comment 2 Paolo Borelli 2014-09-04 06:21:09 UTC
(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
Comment 3 Allison Karlitskaya (desrt) 2014-09-04 14:16:49 UTC
I only find the service check to be suspicious....

btw: this bug has nothing to do with GNotification :)
Comment 4 Paolo Borelli 2014-09-04 16:09:38 UTC
(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
Comment 5 Lasse Schuirmann 2014-11-26 20:12:07 UTC
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)
Comment 6 Allison Karlitskaya (desrt) 2014-11-26 20:54:09 UTC
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...
Comment 7 Lasse Schuirmann 2014-11-26 21:11:35 UTC
(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.
Comment 8 Lasse Schuirmann 2014-11-27 09:35:26 UTC
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.
Comment 9 Alexandre Franke 2015-11-04 14:44:06 UTC
*** Bug 689082 has been marked as a duplicate of this bug. ***
Comment 10 Petr Pulc 2016-08-10 06:54:17 UTC
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).
Comment 11 Michael Catanzaro 2017-08-24 20:39:18 UTC
*** Bug 772819 has been marked as a duplicate of this bug. ***
Comment 12 Ricardo Ramos 2017-10-23 18:35:15 UTC
*** Bug 772820 has been marked as a duplicate of this bug. ***
Comment 13 Chris Murphy 2017-11-10 01:31:56 UTC
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.
Comment 14 Michael Catanzaro 2017-11-10 14:56:21 UTC
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
Comment 15 Iain Lane 2018-01-18 17:34:00 UTC
(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.
Comment 16 Bastien Nocera 2018-01-18 18:10:42 UTC
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.).
Comment 17 Gergely POLONKAI 2018-02-27 09:09:01 UTC
> 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.
Comment 18 Alexandre Franke 2020-11-24 11:59:27 UTC
Superseded by https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/1