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.
