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
The color chosen in the new calendar page is currently ignored
when creating a new calendar, as described in #681.
Added a callback similar to that used for the name text entry,
allowing new calendars to be created with the chosen color.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/681
The entire dialog is wrapped under a scrolled window, it
doesn't make much sense to have yet another one for the
notes. This is a relif of times when the edit dialog didn't
have a scrolled window.
Remove the scrolled window of the notes section.
We want them to grow a bit more, and not let the expansion
of the title label detemine the width. Allow the location
and title entries to expand, and set a maximum width char
to 30 on them.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/554
Using dialog responses to communicate intent to GcalWindow was always
a hack, and as the code is cleaned, it's getting increasingly annoying.
Replace this with a proper 'remove-event' signal ('delete-event' would
conflict with the equally named GTK signal), remove the custom response
types, and cleanup the code.
In on_calendar_monitor_completed_cb() we have this assert:
g_assert (self->completed_calendars <= g_hash_table_size (self->calendars));
That is comparing a signed integer to unsigned. This is dangerous. We
could add casts to say that we really want to do it, but
completed_calendars should never be negative, so might as well use
unsigned.
Since 78cb11c64d, GcalCalendarMonitor now
notifies when a completed calendar transitions to incomplete, and
GcalTimeline decrements its completed_calendars counter. But we forgot
to remove the code that resets completed_calendars when previously
needed. That's not required anymore, because we can trust
GcalCalendarMonitor to do the right thing.
In my case, I have 5 calendars enabled and 6 total. When starting
gnome-calendar, all 5 are successively completed, and
completed_calendars increments from 0 -> 1 -> 2 -> 3 -> 4 -> 5. Then,
when transitioning month view from January 2020 to December 2019, we
call reset_completed_calendars() and completed_calenders gets clobbered
to 0. Then it decrements from 0 -> -1 -> -2 -> -3 -> -4 -> -5 as the
GcalCalendarMonitors notify that they are no longer completed. Well,
that is what would happen, if it didn't crash when decrementing to -1.
We assert -1 <= 6 (the total number of calendars) and crash because -1
gets promoted to a huge unsigned int, since we're comparing signed to
unsigned. (That crash would have been avoided if we used
-Wsign-compare, although that warning would not have caught the logic
problem.)
Anyway, since GcalMonitor now notifies when calendars are no longer
complete, it is safe to simply remove reset_completed_calendars().
GcalTimeline will still notify if it needs to change its own complete
property (in on_calendar_monitor_completed_cb).
Fixes#567Fixes#636Fixes#638Fixes#647Fixes#650
