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
The Google Meet URL is extracted from the Calendar Event Notes by using a substring with a fixed length. This length is too short by 1 character.
In order to get the right URL the substring needs to be 1 character longer. In order to match the Google Meet URL add an "x" in the given URL pattern.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/749
GcalEventPopover gives a preview of the event, and handy access
to the event description and information. It also allows easily
joining meetings if any one if available.
The list of supported meeting URLs is small now, but I hope
more people will contribute as we go.
It is also possible to edit the event through an edit button.
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.
Add missing accelerator for <Alt>+Down as it was
mentioned in shortcuts dialog but not implemented.
Fixes#492
Signed-off-by: Rajat Jain <rajatjain.ix@gmail.com>
Zero length ranges, such as for events without a DTEND could be
considered to overlap a range if they were at exactly the end of the
range. The end of a range however is the first date that is supposed to
not overlap, so a zero-length range on exactly this point should not be
considered overlapping.
This fixes cases where all-day events from the next month could show up
on the same day of the current month if they did not have a DTEND.
This also adds tests for all possible cases of such zero-length events
overlapping.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/701
Currently, GNOME Calendar does not set up the contact_info needed in
libgweather 40 API. This leads to the following assertion, and no
weather forecast info being shown in Calendar:
`gweather_info_update: assertion 'info->contact_info != NULL' failed.`
To fix the assertion, set the URL to the DOAP file on the master branch.
GNOME Weather does the same, see:
https://gitlab.gnome.org/GNOME/gnome-weather/-/commit/6763f7dc9cb25eac4aa13e94e07ea932a42c8e4d
Part of #682
Commit 2d5b1aa9d1 removed the
GCAL_WINDOW_VIEW_DAY variant of the GcalWindowView enum. Since then, the
change-view accelerators to switch to GCAL_WINDOW_VIEW_{WEEK,MONTH,YEAR}
were broken, as the accelerator setup was assuming
GCAL_WINDOW_VIEW_WEEK==1, which isn't true anymore with
GCAL_WINDOW_VIEW_DAY being gone.
This change fixes the enum values in the accelerator setup.
On systems without anything providing the org.freedesktop.timedate1
interface, the timezone returned by the monitor would always be NULL,
because it was never set. This can lead to crashes in places that expect
the monitor to always return a valid timezone. So in that case use the
local timezone from when the monitor got initialized.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/703
