Currently, GcalManager always assumes E_CAL_OBJ_MOD_THIS
when modifying or deleting events. Since we're landing
the groundwork for recurrence management, we can't assume
this anymore.
This patch, then, allows GcalManager:modify_event() and
:remove_event() receive the ECalObjModType instead of
assuming E_CAL_OBJ_MOD_THIS. However, this commit does
not add recurrence support yet, and every call to these
functions are still passing E_CAL_OBJ_MOD_THIS.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
g_strcmp0() is used when comparing the display name of the ESource.
This is not a valid sort, because in this case we will get an order
like "a" < "z" < "B" < "Z", but it should be like "a", "B", "z", "Z".
We will use g_ascii_strcasecmp to fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
The function is supposed to run once every minute. So after
the function is run, just remove it from main thread. So that it won't
act as a time bomb.
https://bugzilla.gnome.org/show_bug.cgi?id=781081
The current implementation is deficient in many ways, the
worst one being the it relying on GObject semi-synchronous
property emission.
This issue was exposed by the Week view code, where the active
date was updated, but delayed to reach the Week header and some
events were being added ~before~ the active date changed.
With this work, I was also able to figure out a bunch of code
that relied on this (i.e. luck) to work.
Previous commits broke the week view's date range (more
than it was already broken). This patch fixes that by
using the correct method to get the week start.
https://bugzilla.gnome.org/show_bug.cgi?id=779967
Earlier the app used to crash when a new event was added using the
'Edit Details' buttion/dialog. This was happening because edit dialog's
event was set to NULL before the event was being stored in the calendar
through the 'edit_dialog' and hence the app was crashing.
This patch fixes the above-mentioned issue by saving the event before
setting the edit dialog's event to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=779733
The week view was being subscribed to the wrong dates,
because the window was miscalculating the start of week
on sundays.
Fix that by properly calculating the start of week offset.
Currently, we keep the to-be-edited event of the Edit
dialog when it sends any response. However, this can
cause issues since we can edit the event, press Esc and
see that the event didn't change but Edit dialog keeps
the changes.
Fix that by always resetting the edited event to NULL
after a response.
https://bugzilla.gnome.org/show_bug.cgi?id=778644
And also be sure to set its pointer to NULL by using g_clear_pointer()
8,830 (24 direct, 8,806 indirect) bytes in 1 blocks are
definitely lost in loss record 17,999 of 18,078
at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
by 0x99CE981: g_malloc0 (gmem.c:124)
by 0x99CEC64: g_malloc0_n (gmem.c:355)
by 0x44CD43: show_new_event_widget (gcal-window.c:731)
by 0x976FC57: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2)
by 0x976F6B9: ffi_call (in /usr/lib64/libffi.so.6.0.2)
by 0x952703B: g_cclosure_marshal_generic (gclosure.c:1490)
by 0x95258B9: g_closure_invoke (gclosure.c:804)
by 0x9541D25: signal_emit_unlocked_R (gsignal.c:3635)
by 0x954105C: g_signal_emit_valist (gsignal.c:3391)
by 0x954170B: g_signal_emit_by_name (gsignal.c:3487)
by 0x4324D8: show_popover_for_position (gcal-month-view.c:305)
https://bugzilla.gnome.org/show_bug.cgi?id=772379
If the user quickly performs a search, open up the calendar
and close it immediately after, the timeout for showing the
event is mistakenly called after the window is destroyed and
causes Calendar to crash.
Fix that by keeping the source id tracked, and realizing it
on finalize().
The edit dialog time picker didnt take into account GNOME's hour format.
The edit dialog time picker didnt take into account GNOME's hour format because the desktop settings clock-format from gcal-window was not passed to gcal-edit-dialog.
Now the data is passed through the function gcal_edit_dialog_time_format and everything works as required.
https://bugzilla.gnome.org/show_bug.cgi?id=703321
When the user removes an event, we first hide it and,
after a timeout, we remove it. The problem is that if
the user closes the window before the timeout is fired,
the event never gets deleted.
Fix that by deleting the event on finalize if there's
any event queued.
https://bugzilla.gnome.org/show_bug.cgi?id=762284
