When the old and the new range of the subscribers don't
overlap entirely, we can't use the regular diff algorithm.
It fails quite spectacularly.
Do a full cleanup when ranges don't overlap.
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.)
A batch size of 5 doesn't seem to impact the mainloop
any more than a batch of size 1, but it reduces the
amount of time spinning the loop quite considerably.
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.
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;
| ^~~~~~~~
"event_start" and "event_end" clearly communicate they're the
start and end datetimes of the event. I'm dumb, so I need the
code to tell me what's it about easily.
