With -vvv, say which check stopped people from being invited to an
event: a read-only calendar, a calendar that isn't on a Core's
Nextcloud, or an event organized by someone else.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
libical 4 changed several APIs used by GNOME Calendar:
- libical-glib now provides autoptr cleanup for ICalTime, so only
define it ourselves for older versions.
- i_cal_recurrence_get/set_by_day() were removed in favor of the
dynamically sized by-rule arrays; add local helpers on top of
i_cal_recurrence_get/set_by().
- i_cal_errno_return() was renamed to i_cal_error_icalerrno().
Also make the create-tzid event test independent of line folding,
which differs between libical versions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The search suggestions popover is styled as a menu ("menu" style)
below the search entry. In recent GTK 4, when has-arrow is TRUE (the
default) and the popover has no arrow geometry or valid parent coordinates,
gtk_popover_create_arrow_path() returns NULL, leaving arrow_render_node NULL.
gtk_popover_snapshot() then appends NULL to the snapshot, causing a fatal
critical crash (GSK_IS_RENDER_NODE assertion failed) upon showing search results.
Setting "has-arrow: false" matches the menu popover design and avoids
the crash. Also guard escape_markup_cb() against NULL strings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
When a label has empty text or an empty PangoLayout,
gtk_snapshot_free_to_node() returns NULL. Passing NULL to
gtk_snapshot_append_node() triggers a critical assertion failure
which causes an abort under G_DEBUG=fatal-criticals.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
In gcal_calendar_monitor_init(), self->shared.lock is initialized with
g_rw_lock_init(). On Linux/glibc, GRWLock allocates memory for the
underlying pthread_rwlock_t (56 bytes).
Because g_rw_lock_clear() was never called in gcal_calendar_monitor_finalize(),
every finalized GcalCalendarMonitor leaked its lock resources, failing the
LeakSanitizer CI build when test_calendar_monitor_expand_recurrences was added.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
When searching for events, users are typically interested in finding the
event rather than seeing a repetitive list of every occurrence instance.
By configuring the search timelines with "expand-recurrences" set to FALSE,
recurring events are loaded as their single master component instead of
expanding all individual occurrences.
Additionally:
- Update GcalSearchHitEvent subtitle to display "Recurring" (e.g. "Tomorrow • Recurring"
or "Recurring") when the event has a recurrence rule.
- Safeguard gcal_event_format_date() when running without a default GApplication.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/991
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
Add an "expand-recurrences" boolean property (defaulting to TRUE) to both
GcalCalendarMonitor and GcalTimeline. When set to FALSE:
- Recurring master components are kept as single events without expanding
each recurrence instance.
- Detached recurrence instances are ignored.
- Pruning outside range retains recurring master events so they are not
prematurely removed.
- Subscriber filtering permits recurring master events within the
subscriber model.
This allows consumers like search providers to avoid expanding all recurrence
instances when searching, improving performance and avoiding duplicate hits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
When tabbing into a grid or list of items that are selectable,
we want to focus the selected item when entering it. At the moment,
we only focus the first or last item in the date chooser grid,
rather than the selected item.
Co-authored-by: Niklas Wimmer <niklas@viric.eu>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/869>
This menu item was found to be confusing in a small experiment with 3
people. Since online calendars are already accessible when adding
calendars in the calendar management dialog, this menu item can be
removed.
Closes#1642
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/876>
Instead of checking `g_date_time_get_week_of_year()`, which doesn't
care about "first day of week" settings, we use our
`gcal_date_time_get_start_of_week()` utility function. This function
determines the first day of the week the passed date belongs to,
constructs a new `GDateTime` object that represents the first day
of week as 'Y-M-D 00:00:00' in local timezone, all while taking
into account the "first day of week" Desktop setting.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1212>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/868>
Since we now have fatal criticals enabled, we are prone to crashes
caused by our external dependencies emitting criticals. The newest case
is the Adwaita About dialog. The critical happened because `ministream`
couldn't find a release tag for 52.0
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/864>
`add_event_to_block()` assumes that the child widget has never been
parented, so it will always set the parent widget when the widget
is already parented, which triggers a critical error in GTK.
This patch addresses this situation by only parenting when the
widget has just been created. Additionally, it asserts that the
parent widget is `self` in the end, so that it crashes if this
is incorrect.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1643>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/863>
`g_dbus_proxy_call_sync` will return NULL and set the recoverable
`error` in case of failure.
We didn't catch this previously so reading the variant from the return
value caused a CRITICAL because a user didn't have the `week-start-day`
setting (introduced in 50.alpha) and the returned `GVariant` was NULL.
Now, we check whether en error is set after calling
`g_dbus_proxy_call_sync` and propagate it to the calling method so it
can gracefully handle it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/862>
The `gcal_agenda_view_first_weekday_changed` uses the same
`gtk_list_view_scroll_to` method that expects the scroll position to be
smaller than the number of items in the list model.
When the list model contains no items, the method reports a critical
which crashes the Calendar whith `fatal-criticals` enabled.
This is the same fix that Georges made in the
`gcal_agenda_view_set_date` method. We now check the number of items
before trying to scroll the list view to position zero.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/861>
It's possible to change the density of the week view, but only through
pinch-zooming or Ctrl+scroll wheel. This means it can't be done with
only the keyboard, and since neither of these methods are documented,
it's not discoverable either.
This adds shortcuts for zooming the view in and out, and documents them
in the shortcuts dialog to make them discoverable.
Helps #1556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/859>
We discussed this on Matrix multiple times and came to the conclusion
that crashing the application is preferred on Nightly and during
development. We often miss a critical log message during development
because it gets swamped by all the other logs. Now we can no longer
ignore them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/857>
`gtk_list_view_scroll_to()` is documented to require that `pos` is
smaller than the number of items in the model. We were not checking
if the model was empty before calling this function, which could
lead to criticals.
Check if the listview model has any items before scrolling it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/860>
davidandClaude Opus 5.5