By using finalize and dispose methods and calling the proper free method.
8,806 (64 direct, 8,742 indirect) bytes in 2 blocks are definitely lost in loss record 18,051 of 18,131
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26A95: g_slice_alloc0 (gslice.c:1051)
by 0x99E8DC4: g_date_time_alloc (gdatetime.c:428)
by 0x99E95C1: g_date_time_new (gdatetime.c:957)
by 0x99E97B2: g_date_time_new_local (gdatetime.c:1012)
by 0x4251F4: multi_choice_changed (gcal-date-chooser.c:419)
by 0x9567F16: g_cclosure_marshal_VOID__PARAM (gmarshal.c:1832)
by 0x95638B9: g_closure_invoke (gclosure.c:804)
by 0x957FD25: signal_emit_unlocked_R (gsignal.c:3635)
by 0x957F05C: g_signal_emit_valist (gsignal.c:3391)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
By using finalize and dispose methods and calling the proper free
methods calls.
8,806 (64 direct, 8,742 indirect) bytes in 2 blocks are definitely lost in loss record 18,367 of 18,534
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26A95: g_slice_alloc0 (gslice.c:1051)
by 0x99E8DC4: g_date_time_alloc (gdatetime.c:428)
by 0x99E8FA3: g_date_time_from_instant (gdatetime.c:524)
by 0x99E933F: g_date_time_new_from_timeval (gdatetime.c:647)
by 0x99E93A5: g_date_time_new_now (gdatetime.c:705)
by 0x99E93C4: g_date_time_new_now_local (gdatetime.c:728)
by 0x445BED: gcal_time_selector_init (gcal-time-selector.c:249)
by 0x9584B32: g_type_create_instance (gtype.c:1866)
by 0x956BED0: g_object_new_internal (gobject.c:1783)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
23,776 bytes in 743 blocks are definitely lost in loss record 19,053 of 19,159
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26AD7: g_slice_copy (gslice.c:1076)
by 0x6A97912: gdk_rgba_copy (gdkrgba.c:76)
by 0x42B35E: gcal_event_set_color (gcal-event.c:750)
by 0x42BF3E: gcal_event_set_source (gcal-event.c:1204)
by 0x42AE20: gcal_event_set_property (gcal-event.c:481)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
28,337 bytes in 415 blocks are definitely lost in loss record 18,432 of 18,507
at 0x4C2FC47: realloc (vg_replace_malloc.c:785)
by 0xA88021D: vasprintf (in /usr/lib64/libc-2.24.so)
by 0x9A593FC: g_vasprintf (gprintf.c:316)
by 0x9A292F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0x9A2939C: g_strdup_printf (gstrfuncs.c:540)
by 0x42A10B: gcal_event_update_uid_internal (gcal-event.c:192)
by 0x42BF52: gcal_event_set_source (gcal-event.c:1217)
by 0x42ADCA: gcal_event_set_property (gcal-event.c:480)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
29,717 (8,128 direct, 21,589 indirect) bytes in 508 blocks are definitely lost in loss record 18,380 of 18,445
at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
by 0x9A0C981: g_malloc0 (gmem.c:124)
by 0x9A0CC64: g_malloc0_n (gmem.c:355)
by 0x5BE3948: e_cal_component_get_id (e-cal-component.c:1477)
by 0x42A06D: gcal_event_update_uid_internal (gcal-event.c:178)
by 0x42A64D: gcal_event_set_component_internal (gcal-event.c:310)
by 0x42AD0F: gcal_event_set_property (gcal-event.c:459)
by 0x956B39B: object_set_property (gobject.c:1423)
by 0x956BFDF: g_object_new_internal (gobject.c:1817)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
by 0x878933A: g_initable_new (ginitable.c:146)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
105,858 (42,064 direct, 63,794 indirect) bytes in 478 blocks are definitely lost in loss record 19,065 of 19,103
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x99F0510: g_hash_table_new_full (ghash.c:711)
by 0x42B10C: gcal_event_init (gcal-event.c:657)
by 0x9584B32: g_type_create_instance (gtype.c:1866)
by 0x956BED0: g_object_new_internal (gobject.c:1783)
by 0x956CB24: g_object_new_valist (gobject.c:2042)
by 0x878945D: g_initable_new_valist (ginitable.c:224)
by 0x878933A: g_initable_new (ginitable.c:146)
by 0x42B181: gcal_event_new (gcal-event.c:690)
by 0x4549CA: gcal_year_view_component_added (gcal-year-view.c:1632)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
264,180 (1,920 direct, 262,260 indirect) bytes in 60 blocks are definitely lost in loss record 18,487 of 18,509
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0x9A0C90E: g_malloc (gmem.c:94)
by 0x9A26A55: g_slice_alloc (gslice.c:1025)
by 0x9A26A95: g_slice_alloc0 (gslice.c:1051)
by 0x99E8DC4: g_date_time_alloc (gdatetime.c:428)
by 0x99E95C1: g_date_time_new (gdatetime.c:957)
by 0x99E97B2: g_date_time_new_local (gdatetime.c:1012)
by 0x42481C: calendar_compute_days (gcal-date-chooser.c:150)
by 0x425F3B: gcal_date_chooser_set_date (gcal-date-chooser.c:743)
by 0x4251CD: multi_choice_changed (gcal-date-chooser.c:420)
by 0x9567F16: g_cclosure_marshal_VOID__PARAM (gmarshal.c:1832)
by 0x95638B9: g_closure_invoke (gclosure.c:804)
https://bugzilla.gnome.org/show_bug.cgi?id=772272
Following the previous work on month view, this commit
implements scrolling capabilities to Year view. We do
this not only with the :scroll-event, but also using the
:edge-overshot signal of GtkScrolledWindow.
It is very natural and intuitive to try and change the current date
by scrolling. The current implementation of the Month view, however,
blatantly ignores scroll events.
Fix that by hearing to the scrolling events and changing the month
when the scroll is enough.
When the event widget's GdkWindow receives an event scroll,
the event is lost because it doesn't handle it. It should,
however, propagate the scroll event so that the container
is able to properly parse it.
Fix that by making GcalEventWidget listen and propagate
scrolled events.
Since now we manually manage the headerbar title and subtitle, setting
them via GtkHeaderBar API won't have any effect.
Fix that by directly setting the subtitle label.
https://bugzilla.gnome.org/show_bug.cgi?id=771565
If the user tries to drop a e.g. file, GNOME Calendar crashes
immediately.
While the desired behavior would be checking if that's an ics file,
lets just not crash for now.
https://bugzilla.gnome.org/show_bug.cgi?id=771680
When the user starts a drag operation from the overflow popover,
it should hide itself, otherwise it can block dropping the event
below it. Currently, this is not what happens.
Fix that by making the overflow popover a drag and drop target,
and hide it when it detects drag movement.
https://bugzilla.gnome.org/show_bug.cgi?id=771663
Since we need to special-case the datetimes to deal with UTC
all day events, using a general local GTimeZone would cause
the cloned all-day events to show wrongly inside the popover.
Fix that by calculating each event's start and end dates according
to the all day events.
https://bugzilla.gnome.org/show_bug.cgi?id=771655
Some compilers seem to be over-pessimistic and abort the build with:
gcal-month-view.c: In function 'gcal_month_view_drag_drop':
gcal-month-view.c:908:32: error: 'timespan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
GDateTime *new_end = g_date_time_add (new_start, timespan);
Even though the usage of the variable is guarded by an equal if as the assignment
https://bugzilla.gnome.org/show_bug.cgi?id=770667
GNOME_COMPILE_WARNINGS is still being used, despite its deprecated
status. This commit also tweaks configure.ac a little, removing
redundant macro calls and definitions and quoting all macro arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=770466
In this commit, we changed the background area of current day.
Presently, the current day is highlighted by the number. This makes difficult for the user to identify it when there are lot of events.
To fix this, we changed the color of background and made background area equal to the cell's area.
https://bugzilla.gnome.org/show_bug.cgi?id=755946
Currently, the end date is set by calling gcal_event_set_date_end() with
new_start instead of new_end, which is incorrect.
With the former issue fixed, the difference evaluates to one less than
required when dragging to a later date. This can be fixed by calculating
the drop date by adding to the start date and adding the difference.
This commit fixes both issues.
https://bugzilla.gnome.org/show_bug.cgi?id=769470
Currently, the event is moved by a number of cells, calculated from the
start date and the cell index. The problem with that is that it does not
work with events, whose start and end dates of which are on different
months or years. This commit changes the logic so that the start date is
calculated by taking the year and month difference into consideration
and the end date is set by adding the event length to the adjusted start
date.
https://bugzilla.gnome.org/show_bug.cgi?id=769470
Currently, all-day multi-day events are displayed inconsistently with
regard to other calendar applications. That is due to strict following
of RFC 5545, which mandates non-inclusive all-day multi-day event end
dates. This commit makes the edit dialog display a faked date for such
events.
https://bugzilla.gnome.org/show_bug.cgi?id=769300
Currently, the hour component of the time is doubled when switching from
AM to PM, which is incorrect. This commit fixes the logic by adding 12
hours when switching to PM.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
If GcalEditDialog.format_24h is initialized to zero, the call to
gcal_edit_dialog_set_time_format() from GcalWindow will not make
period_combo boxes visible on systems, where 12-hour clocks are used.
This commit fixes that by removing the if statement from the function.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
Function calendar_get_week_start do the same things with the same code as
function get_first_weekday, so it is better to remove calendar_get_week_start
and switch all the use of calendar_get_week_start to get_first_weekday.
This also fixes build problems on non-glibc systems because get_first_weekday
provides fallback for non-glibc systems.
https://bugzilla.gnome.org/show_bug.cgi?id=769140
To keep the current date chooser in sync with
GNOME Shell, tweak the week names to show only
the first, upcased letter of the week name.
Also, this commit avoids making day number circles
ellipses when the week number is not present.
The current implementation of the new calendar widget
accepts showing the week numbers in a modern and much
more consistent way.
The behavior, however, is not aligned with the rest of
the application and the desktop, which share a setting
to show or hide the week number.
Fix that by synchronizing the new calendar's week number
property with the specific setting.
After making the date selector use the brand
new date chooser widget, it is now time to make
it an entry.
This commit, then turns GcalDateSelector into a
GtkEntry subclass, and add all the plumbing that
is necessary to make it work as such.
As a side effect, this commit adds rudimentary
natural language support for parsing dates.
