This issue does not directly concern code in this repository, or in this organization, for that matter. However, it was suggested to me in the AsteroidOS Matrix room to post it here in addition to sailfishos, to potentially increase activity.
Description:
AlarmsModel only subscribes to the alarm_triggers_changed signal from the timed daemon (via TimedInterface). The handler alarmTriggersChanged uses this signal to update the enabled state of already-known AlarmObject instances, but does not handle the case where the trigger map contains cookies that are unknown to the model (alarms created by other processes).
As a result, if an AlarmsModel instance is running in process A, and process B creates a new alarm, process A's model will never reflect it. rowCount() stays the same and the new alarm is invisible.
When an alarm is deleted, its cookie disappears from the trigger map, and alarmTriggersChanged sets enabled to false on the corresponding AlarmObject. The row is never removed from the model, but the enabled flag does update correctly.
Steps to reproduce:
- Instantiate
AlarmsModel with onlyCountdown: true in a watchface (process A)
- Open the timer app (process B) and start a timer, this creates a countdown alarm
- Observe that the watchface model's
rowCount() remains 0 and the alarm is not visible
- Stop the timer, then start it again
- Observe that
rowCount() remains 0 for the new alarm
Root cause:
TimedInterface (the wrapper for Maemo::Timed::Interface in nemo-qml-plugin-alarms) only connects alarm_triggers_changed, and its handler alarmTriggersChanged in AlarmsBackendModelPriv only iterates over already known alarms. Entries present in the incoming trigger map but not in the model's alarm list are silently ignored.
Expected behavior:
AlarmsModel should stay in sync with the timed daemon regardless of which process creates alarms.
Suggested fix:
In AlarmsBackendModelPriv::alarmTriggersChanged, after processing known alarms, check whether the incoming triggerMap contains any entries not present in the current alarms list. If so, trigger a fresh populate() call to pick up the unknown alarms.
This issue does not directly concern code in this repository, or in this organization, for that matter. However, it was suggested to me in the AsteroidOS Matrix room to post it here in addition to sailfishos, to potentially increase activity.
Description:
AlarmsModelonly subscribes to thealarm_triggers_changedsignal from thetimeddaemon (viaTimedInterface). The handleralarmTriggersChangeduses this signal to update the enabled state of already-knownAlarmObjectinstances, but does not handle the case where the trigger map contains cookies that are unknown to the model (alarms created by other processes).As a result, if an
AlarmsModelinstance is running in process A, and process B creates a new alarm, process A's model will never reflect it.rowCount()stays the same and the new alarm is invisible.When an alarm is deleted, its cookie disappears from the trigger map, and
alarmTriggersChangedsetsenabledtofalseon the correspondingAlarmObject. The row is never removed from the model, but theenabledflag does update correctly.Steps to reproduce:
AlarmsModelwithonlyCountdown: truein a watchface (process A)rowCount()remains 0 and the alarm is not visiblerowCount()remains 0 for the new alarmRoot cause:
TimedInterface(the wrapper forMaemo::Timed::Interfaceinnemo-qml-plugin-alarms) only connectsalarm_triggers_changed, and its handleralarmTriggersChangedinAlarmsBackendModelPrivonly iterates over already known alarms. Entries present in the incoming trigger map but not in the model's alarm list are silently ignored.Expected behavior:
AlarmsModelshould stay in sync with thetimeddaemon regardless of which process creates alarms.Suggested fix:
In
AlarmsBackendModelPriv::alarmTriggersChanged, after processing known alarms, check whether the incomingtriggerMapcontains any entries not present in the current alarms list. If so, trigger a freshpopulate()call to pick up the unknown alarms.