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.
This commit sets up the edit dialog from the window's ui
resource file, in a series of commits that tries to move
all C code to the UI definitions.
Also, GcalManager is a full GObject class, not a simple
pointer. As such, update the property spec to be of type
object, not pointer.
Add the new signal for GcalManager::source-enabled that
notifies connected widgets about the source change. With
that, we can keep checkboxes syncronizes.
