When deleting events with recurrence, we want to hide the event
widgets according to the modification type. So that selecting
e.g. subsequent in the modification type dialog hides the event,
and the subsequent ones, truly reflecting the operation that will
happen.
Currently, however, the views don't do that, and only hide the
event that was asked to be deleted.
Fix that by passing the object modification type, and adapting the
views to take that into account.
Currently, on the year view, Saturday and Sunday are marked
as non working days by default, despite the Locale settings and the
fact that in some Countries Sunday and/or Saturday are workdays.
This patch introduces a new function "is_workday" to check
whether a day is a working day according to the territory part of
Locale.
https://bugzilla.gnome.org/show_bug.cgi?id=746927
Setting the recurrence-dialog transient for toplevel widget
allows us to take care of
ask_recurrence_modification_type() calls in the
various views.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Whenever a user chooses to modify an event which is
recurring, a new dialog will open automatically when
the user clicks 'Done' or 'Delete' in edit-dialog,
after making the desired changes. This new dialog
will ask the user to choose the set of events to
which the changes will be applied. The options
include 'This Event Only', 'Subsequent Events'
and 'All Events'. The function returns true and
the changes take place only if the user chooses any
option other than 'Cancel' or <Alt+F4>.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
It is very natural and intuitive to try and change the current date
by scrolling. The current implementation of the Month view, however,
blatantly ignores scroll events.
Fix that by hearing to the scrolling events and changing the month
when the scroll is enough.
Calendar is not handling locale correctly, e.g. user’ set language to
English (en-us) and format to Norwegian (nb-no), but Calendar assumes
English format rather than Norwegian.
Calendar code was ready to use the correct format, just like Shell and
GtkCalendar. The issue was in the build script which was setting the
correct locale variable responsible to make that code work.
This patch fixes the build script.
https://bugzilla.gnome.org/show_bug.cgi?id=762428
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
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.
+ get_color_name_from_source
+ get_circle_pixbuf_from_color
The first one is use plenty in the codebase, everytime we need a color,
and the second one will be used when retrieving the search results.
We were relying on _NL_TIME_FIRST_WEEKDAY, which is a glibc extension.
It doesn't work with non-glibc systems, such as FreeBSD.
This commit makes it carefully search for the first weekday. Fixes bug #743327.
Fix the sigsegv in edit-dialog and event-widgets when there's no
end-date set.
Set a guard in Utils::gcal_dup_icaltime function.
There's still some problems with the events showing the first time but
not anymore.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736002
