format_utc_offset can be called with the return value of
g_date_time_get_utc_offset returning microseconds in a gint64. It is
also still called with the return value of icaltimezone_get_utc_offset
in seconds. Deal with both.
https://bugzilla.gnome.org/show_bug.cgi?id=762438
Week numbers in year view was using a small and very light style and
that was making difficult for users to be able to read it.
After a few conversation with gnome-design team, they proposed the best
approach it would be to use the same style as gnome-shell panel does.
The week numbers style was changed to be as close as possible to the
gnome-shell panel.
https://bugzilla.gnome.org/show_bug.cgi?id=759354
When we finalize, we remove the event. Normally this means
that the event also gets finalized, as the widget almost
always holds the only reference to the event.
However, there are some rare cases where we finalize the widget
but not the event. If the event the updates the color or the
summary, we try to redraw the finalized widget and crash.
Fix that by disconnecting the signals when finalizing the widget.
When the user removes an event, we first hide it and,
after a timeout, we remove it. The problem is that if
the user closes the window before the timeout is fired,
the event never gets deleted.
Fix that by deleting the event on finalize if there's
any event queued.
https://bugzilla.gnome.org/show_bug.cgi?id=762284
By using gtk_dialog_run(), we enter in a recursive mainloop
which blocks the parent's one. Because of that, we see weird
things like the quick add popover not still floating around.
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.
The compare_for_single_day() method is reproducing the
same functionality from gcal_event_compare(), and the only
consumer is the Year View. So, for now, simplify the
comparing function and put it in year view file.
Also, this commit vastly improves and documents the year
view's algorithm to add events to the sidebar list.
Sometimes we crash the window right after closing it
because we set a timeout for save_geometry() before
destroying it, and the timeout is called after the
window is destroyed.
Using a GDateTime improves consistency with the
other components (ideally, we'll move completely
to GDateTime) and simplifies the code.
This commit adds a new property GcalDateSelector::date
and adapts the API to use GDateTime.
Instead of using the GcalEventData struct, use the
deleted event. It holds a reference until the event
gets destroyed.
With this commit, we can safely drop GcalEventData
structure, since it's not used anymore.
Instead of relying on the now deprecated GcalEventData,
use the newly introduced GcalEvent class. As a side
effect, the code is simpler and much more saner to
deal with.
Following the sequence of porting commits, make the Shell's
search provider class handle events using GcalEvent classes
instead of the old GcalEventData structure.
Instead of using the ESource + ECalComponent combination,
use the new GcalEvent class, which wraps up and simplifies
most of the code.
This commit adds a GcalEditDialog::event property, and
adapts the dialog (and everything dependant on it's code)
to use the GcalEvent class.
