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
g_source_destroy doesn't free memory, just removes the source from its
main context. We have to do both. (g_source_unref() might call
g_source_destroy() if it has the last ref, but if something else has
another ref, then disaster could result if we don't call it manually.)
Turns out, all we have to do is rewrite the URL to https://. I'm
surprised this works, but I don't see any problems with it. I tested
subscribing to webcal://www.gnome.org/start/unstable/schedule.ics.
See also: #481
Currently, when the user enters an invalid URL -- a URL that does not
pass SoupURI's URI format validation -- then we set the error style
class on the URL entry to turn the border of the entry red. For example,
if I try to enter "dog" then GNOME Calendar catches this and flags the
entry as red.
But there are some problems.
First of all, GNOME Calendar doesn't do anything to prevent users from
entering URLs that are syntatically valid but not usable as calendars.
The code knows whether the URL was successfully parsed as a calendar
file, it just doesn't do anything with this information. So there is no
red warning if I try to use https://example.com as a calendar, even
though the dialog knows that it didn't work.
Secondly, GNOME Calendar allows pressing the Add button even if the URL
entry contains invalid input, but only if the Calendar Name has been
entered. The dialog thinks: "if I have a name, but not a valid URL, then
the user wants to create a new, empty local calendar!" But this is not
right. If the user has typed anything in the URL entry, then the goal is
to import a new calendar, not to create a new one.
This commit changes set_url_entry_error() into update_url_entry_state(),
and gives it responsibility for updating the add button sensitivity and
URL entry pulsing in addition to the URL entry style class, solving both
of the above problems.
As a side effect, this also closes a race window where the Add button
remains sensitive for half a second after typing new text in the URL entry.
At this point, we don't yet know whether the URL is valid, because we
wait half a second before validating the URL, so we shouldn't allow the
user to activate the Add button during this race window.
Fixes#481
This check passes if the URI is empty. Normally this callback only runs
when there is text in the URL entry, but there is a race window where
the user could delete it first. (Passing NULL to a SoupURI creates an
invalid non-NULL empty URI that can be filled in later.)
self->thread can be NULL if gcal_calendar_monitor_set_range() was never
called prior to finalize. This is fine, so just check for NULL here
using g_clear_pointer().
Fixes:
[43/52] Compiling C object 'src/25a6634@@gcal-private@sta/core_gcal-calendar-monitor.c.o'
../../../../Projects/gnome-calendar/src/core/gcal-calendar-monitor.c: In function ‘on_client_view_objects_added_cb’:
../../../../Projects/gnome-calendar/src/core/gcal-calendar-monitor.c:402:16: warning: variable ‘old_size’ set but not used [-Wunused-but-set-variable]
402 | gint old_size;
| ^~~~~~~~
For whatever reason, libical doesn't support the Etc/UTC timezone.
Currently we crash gnome-calendar whenever libical doesn't support the
current timezone (as returned by GTimeZone). Let's fall back to UTC
instead.
Fixes#485
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
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.
Fixes#423
This was originally discovered and fixed by Milan Crha; I'm just
forward-porting his fix to the master branch. self->clients takes
ownership of this source but we don't currently have ownership here,
leading to a double free vulnerability.
Fixes#435
Trying to use environment variables to guess the locale was a good
attempt, but this is tricky because they have to be looked up in a
certain order: first LC_ALL, then fallback to LC_TIME, and finally LANG,
which was missed here. This caused a huge warning spam on the year view
when only LANG is set, and usually only LANG should be set since the
other environment variables are usually used for temporary overrides.
Instead, query the locale using setlocale().
Also, don't assert if the locale is shorter than expected (missing
territory code) since there is at least one valid locale that does not
have any territory codes (Esperanto) and since it's programmer error to
assert when the application processes unexpected input like this.
Fixes#424
We fail to disconnect from the GWeatherInfo in both update_location()
and dispose. We have to fix update_location() manually. To avoid the
need to disconnect in dispose, we can just use g_signal_connect_object().
self->weather_service was only partially removed in 01fdf79e6a,
leading to a guaranteed crash when the weather is updated because
self->weather_service is now always NULL.
Fixes#397
The old code here was not setting tzid correctly. It me took hours to
figure out how to do this, but it turned out to be simple once I found
the right place, buried deep in the e-d-s source code.
Now, ideally we would not change the timezone of the event every time we
edit it. But some big changes in how GNOME Calendar tracks timezone are
going to be required if we do that. In particular, I believe we would
have to stop saving all day events in UTC, and give up on using
GDateTime as we do now, and track timezone completely separately
everywhere using icaltimezone. This is what e-d-s does, and it's
probably what we should be doing too. But that would be a big change.
This commit solves the basic problem, which is to ensure the event is
scheduled for the right time, regardless of timezone.
This finally completely fixes#168.
This reverts commit ce2c955269.
This commit is not right. Lots of code in Calendar relies on being able
to set the timezone of a GcalEvent, and this results in us always
ignoring the timezone set by Calendar in preference to whatever happened
to be in the ECalComponentDateTime previously. That might not be so bad,
but additionally, the time is not adjusted accordingly, so this actually
results in the time of events changing unexpectedly from what Calendar
is trying to set.
The code to explicitly store UTC times for all day events is OK (I
guess) and will be restored in a subsequent commit.
g_date_time_equal() corrects for timezone offsets to ensure that, e.g.,
6 AM CST is treated as equal to 12 PM UTC. This means attempts to change
the start and end times of events to the same time in another timezone
are currently failing. We need to remove this attempt at optimization
because it prevents gcal_event_set_timezone() from ever doing anything.
The tooltips think all events start and end between 1:00 and 1:59,
because we are missing a % in the format string and the I looks like 1.
I like it when bugs turn out to be easy. Fixes#225.
In month view, when clicking on a day of the month, every event is
initially an All Day event until the user opens the Edit Details dialog
and unchecks the checkbox. This means that the event is originally
created in UTC time, and needs to be explicitly switched to local time.
Michael Catanzaro