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
By using gtk_dialog_run(), we enter in a recursive mainloop
which blocks the parent's one. Because of that, we see weird
things like the quick add popover not still floating around.
We don't have to load most of the menus we're currently loading
by using the very handy automatic resource loading.
This patch fixup so the app loads resources automagically.
When we change the calendar color, everything that represents
this calendar must be updated to match the changes. The calendar
popover, however, wasn't aware of these changes and did not match
updates of calendars.
Fix that by destryoing and readding the row for the given calendar
when it changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762069
Sometimes we crash the window right after closing it
because we set a timeout for save_geometry() before
destroying it, and the timeout is called after the
window is destroyed.
Instead of using the GcalEventData struct, use the
deleted event. It holds a reference until the event
gets destroyed.
With this commit, we can safely drop GcalEventData
structure, since it's not used anymore.
Instead of using the ESource + ECalComponent combination,
use the new GcalEvent class, which wraps up and simplifies
most of the code.
This commit adds a GcalEditDialog::event property, and
adapts the dialog (and everything dependant on it's code)
to use the GcalEvent class.
