Cloning an ECalComponent can fail, and we need to be able to
catch these failures.
Assert that cloning was successful before procceeding with
the move.
GcalEditDialog code pre-dates GcalEvent and apply changes directly
to the underlying ECalComponent. However, it doesn't commit the
sequence after doing so, which opens the door for doom.
Commit the component sequence after changing the recurrence data.
When moving an event to another calendar, the GcalEvent instance
that is being held by GcalEditDialog is not valid one. On the other
hand, moving an event shouldn't trigger an update either.
For now, simply fake a GTK_RESPONSE_CANCEL. In the future, it'll
be better to move most of the GcalWindow code to GcalEventDialog
itself.
In locales where the first weekday is a monday, the previous code
had a off by one error determining the week a sunday is in.
The problem ultimately arose because in the
`gcal_date_time_get_start_of_week()` function the variable
`n_days_after_week_start` would become negative (-1 in this case) making
the following `g_date_time_add_days (date, -n_days_after_week_start)`
add 1 day resulting in `start_of_week` being set to the start of the
following week.
The solution was to make sure `n_days_after_week_start` would be
positive by adding 7 to it. The variable is taken modulo 7 hence this
should not introduce any bugs.
Fixes#583
Instead of modifying the original event, create a new event
from it and modify this new event instead. After updating it
through gcal_manager_update_event(), GcalMonthView will remove
the old instance and add the new one anyway.
Edit a cloned event instead of the actual event, so that it
can preserve the original event's integrity. This allows for
a major edit dialog cleanup in the future.
The month view looks specially awful when switching between
dates, since it doesn't implicitly filter the ranges it's
displaying.
Ignore events outside the current month range, since they'll
be removed anyway by the timeline.
The behavior of gcal_range_compare(), and the 'position' argument
of gcal_range_calculate_overlap(), should be the same. However,
because we were comparing the end dates in the wrong order, they
didn't match.
Fix that by properly comparing the end of the ranges.
Moving to have one subscriber per event made us face an interesting
problem: when removing an event, there may be no subscribers that
contain this event, in which case we never queue any REMOVE_EVENT
and the range tree isn't updated.
Add sentinel events (that update the range tree) and subscriber events
(that update subscribers, but not the range tree).
When we add an event to the queue, and later remove it, if the
event is still in the queue, we can just cancel both out and
save the timeline some processing time.
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
