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>
Currently, `gcal_date_time_get_start_of_week()` seems to be
the only user of this macro function. In the next commit, the
month view will use it to traverse weeks while maintaining
the weekday.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/839>
At the moment `gcal_date_chooser_set_date()` is automatically setting
the day to 1, which is undesirable behavior for a method that is
designed to "just" set the date. By connecting to
`GcalMultiChoice::explicitly-changed`, we can simply have the day
set to 1 to accompanying callbacks.
Currently, `multi_choice_changed()` is invoked 50 times at startup.
By using `GcalMultiChoice::explicitly-changed`, `multi_choice_changed()`
is only invoked 10 times. This is still more than ideal, but it's
a significant drop.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1639
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
We currently rely on connecting the `notify::value` signal,
which is emitted every time the value is changed explicitly or
implicitly. This can be problematic when, for example, the user
scrolls in the month view, which changes the value of each
GcalDateChooser widget, and each minor difference will re-emit
the signal until it's over. The `GcalMultiChoice::user-changed`
signal will only emit when the user presses the
previous/next buttons.
The next commit will port GcalDateChooser
to `GcalMultiChoice::user-changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
John Cardullo