I'm testing this out on r276 this morning and am getting confusing results. At first I thought it was an indicator-datetime caching bug, because the modified alarms are being successfully saved to tasks.ics.
However, even if I stop and restart indicator-datetime, the new session of indicator-datetime picks up the old values instead of the updated ones seen in tasks.ics. I added in debug statements to check the timestamps, and yes alarms being returned by indicator-datetime's call to e_cal_client_generate_instances() still have the old values.
However, if I kill and restart evolution-calendar-factory, *then* restart indicator-datetime, it picks up the new, modified versions.
The system is behaving like there's a cached version of the alarms in evolution-calendar-factory that's not getting updated after tasks.ics gets written out after qtorganizer5-eds modifies the objects.
Still present in r276.
I'm testing this out on r276 this morning and am getting confusing results. At first I thought it was an indicator-datetime caching bug, because the modified alarms are being successfully saved to tasks.ics.
However, even if I stop and restart indicator-datetime, the new session of indicator-datetime picks up the old values instead of the updated ones seen in tasks.ics. I added in debug statements to check the timestamps, and yes alarms being returned by indicator- datetime' s call to e_cal_client_ generate_ instances( ) still have the old values.
However, if I kill and restart evolution- calendar- factory, *then* restart indicator-datetime, it picks up the new, modified versions.
The system is behaving like there's a cached version of the alarms in evolution- calendar- factory that's not getting updated after tasks.ics gets written out after qtorganizer5-eds modifies the objects.
Renato, Zsombor, any ideas on this?