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>
Fixes a few problems in the schedule comparison code:
- Same recurrence pointer short-circuits to TRUE: a pointer to the
same recurrence is not a sufficient condition, because the dates
could still be different (this is especially true if the recurrence
is NULL for both events, but also holds if that is not the case).
Also deleted the explicit check if only one of the recurrence
pointers is NULL, because that is the first thing that is checked
in `gcal_recurrence_is_equal()` anyway.
- Date comparisons only check if the date moved into a specific
direction: the correct logic is to check if they are not the same,
no matter in which direction the date moved.
- The time is not compared: for non all-day events, it is necessary
to compare the time values too. The glib function that is now used
for that also checks the date, so these checks can be collapsed
into one.
For the second and third point it seems like some things got a bit
mixed up in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/2ee6dfc5e7bd5823bee5029a7ac3a32d3c247ba9:
- The `gcal_schedule_section_changed()` implementation already used the
`g_date_time_equal()` function (which is now used again).
- It was `gcal_schedule_section_day_changed()` which only compared the
dates using `gcal_date_time_compare_date()`, but this function was
only used for edits to recurring events to determine whether to
allow changing all instances. This commit now exposes a regression
in this part of the code, which is tracked separately in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1612>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/792>
This adds:
- `gcal_event_alarms_equal()`
- `gcal_event_schedule_equal()`
- `gcal_event_strings_equal()`
We aren't going to make use of it yet, but eventually these functions
will be used for the event editor dialog, as well as writing tests for.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
Add a wrapper for the ECalComponentOrganizer. An instance of this type
is kept as part of the GcalEvent structure.
The GcalEventOrganizer is just a "proxy" to the ECalComponentAttendee
and its purpose is to unclutter the GcalEvent interface and provide a
bindable base for a UI widget.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/671>
Creates a chooser managing a GDateTime. The chooser allows the user
to change the date, the time and the timezone independently.
This replaces the precedent GcalTimeChooserRow widget, because it is
easier to manage the different interactions with the user in a single
widget.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
When dealing with floating time events the timezone used was UTC,
but according to RFC5545 when the timezone is not specified the
local timezone should be used.
Fixes#171
This patch do not sends ADD_EVENT for events that are multiday and are
part of the old_range when calling calculate_changed_events. This will
prevent multiday duplicate events to appear in the agenda widget when
using the week view.
If the event is a multiday and it was in the previous range, it won't
send the REMOVE_EVENT so multiday events won't dissapear when it's still
relevant.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/898#note_1602391
While fixing timezone bugs, it was found that the calendar property needs
to be set before the component property. The component times may require
to have the calendar set, to be able to lookup the custom timezones in the
calendar, thus make sure the calendar is set before the component is set,
during the construction time.
Rework the initialization process so that setting the construct-only
component property merely takes a hold on the references; and the actual
setting up of the event happens during g_initable_init().
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/788
If we can't find an appropriate timezone, query the ECalClient
for it and give it an extra chance of finding the right timezone.
Thanks to Milan Crha for proposing this fix.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/444
All-day events always use UTC, so when the multiday detection code was
converting them to the local timezone, they span an additional day if
the local timezone is not the same as UTC. This was leading to all-day
events always being considered multiday events.
Fix this by ignoring the timezone for all-day events, like all other
comparisons do. Also don't consider all-day events spanning 1 day to be
multiday since as per RFC 5545 the end date is non-inclusive and if
omitted to be start + 1 day.
Right now, comparing dates with gcal_date_time_compare_date() gives
the exact opposite result of when comparing using g_date_time_compare().
As shown by this patch, this was a source of *many* bugs.
The return value is nullable, but gnome-calendar fails to check it.
Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().
We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().
Fixes#419
