If we add directly from the quick add popover, the event is
all day by default. If we're editing the event, it may or
may not be an all day event. In that case, if the user decides
to give it a time, we want it to be in the local timezone.
If an event is from a different timezone, the headers of
the overflown popover should be translated to the current
timezone.
For example, if an event happens at 17h -0300, the translated
hour is 22h +0200. The current code already handles these
differnces, but the listbox row wasn't updated.
After we added GcalEvent::is_multiday(), there is no need to
wrap it in a vfunc anymore.
To fix it, simply use is_multiday() function and get rid of the
vfunc.
We don't have to load most of the menus we're currently loading
by using the very handy automatic resource loading.
This patch fixup so the app loads resources automagically.
When we change the calendar color, everything that represents
this calendar must be updated to match the changes. The calendar
popover, however, wasn't aware of these changes and did not match
updates of calendars.
Fix that by destryoing and readding the row for the given calendar
when it changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762069
Instead of throwing it all for GcalWindow to handle,
add a new class called GcalQuickAddPopover that handles
event creation.
Events are always all day when created from the quick
add popover, unless the user wants to change it and click
'Edit Details' button.
In the future, we'll look forward adding natural language
support, so the user can type the times directly from the
entry (like e.g. "soccer at park from 10am to 11:30am").
I don't know the reasoning behind it, but sometimes
I see dates like March 32 or February 30. Events are
correctly added, so I suspect it's an issue with another
app.
In any case, we should be able to handle weird dates
without crashing, so normalize the dates before using
them.
The subscriber does not add components who are already
added to the view - and doesn't need to do it. To overcome
that fact, we have to reallocate the events even when
nothing was added.
Fix that by setting the GcalSubscriberView->children_changed
to TRUE and queueing an allocation right after the date
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762066
Conceptually, we need to compare the event's dates to make
sure we're allocating the widgets correctly, as widget's
dates may not represent the event's ones.
GcalEventWidget added API to automatically change
the widget rendering according to the initial and
final dates. Month view, however, was still handling
it manually (and wrongly).
Fix that by reworking the allocation code, documenting
it and using the apropriate API from GcalEventWidget.
Using libical with libecal means that the dates
are always stored as UTF dates, and we receive the
timezone as the ECalComponentDateTime::tzid value.
This fact was net being considered when adding date
support on GcalEvent, and was causing various issues
when displaying dates.
Fix that by properly handling timezones in GcalEvent.
When we change a source (aka agenda) color, we have to
restart Calendar in order to see it in action.
After the work on GcalEvent, events are now able to track
the agenda's color changes, and the event widget updates
itself in response to that.
The last step was simple notifying GcalApplication when an
agenda changes, so it knows when to recreate the color schemes.
