The calendar's timezone cache holds only timezones already received
or added to the calendar, thus when asking it for a timezone for "the first
time", it returns NULL and a wrong timezone is used instead.
The get_timezone() does not do any I/O when the timezone is already cached
on the client side, thus it's fine to use it.
This could exhibit with non-recurring events, which use custom time zones,
in which case the event is shown in a wrong time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2145>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
app_notify_events_added uses an intermediate builder to construct an
array that is then added to the main variant using g_variant_builder_add
which should clear the intermediate, but doesn't due to the way it is
passed: by value, rather than as a pointer.
This was debugged with the help of Eduardo Habkost, who believes it
works on x86 due to big structs being passed as pointers.
Fixed: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3440
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1848>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
The HasCalendar property reflects whether there are any views, and views
change either when clients appear/disappear or when the time range changes.
However we currently only emit the PropertiesChanged signal for the former,
fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1300
Since commit 28c535e34, we use the timezone associated with the ICalTime
instead of the default timezone when converting to time_t. However while
that is correct for most events, for ICalTimes that don't have a timezone
associated we still want to fall back to the default timezone instead of
UTC.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1895
Evolution draws in libsoup, which exposes deprecated types in its
API. While its headers have been fixed to guard the affected symbols,
those fixes aren't in our CI images yet.
Until we get a fixed version, just disable all deprecation warnings
during the include in order to not trip over "foreign" bugs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We aren't using any deprecated evolution-data-server API, so we can
turn it off; this avoids compiler warnings for glib deprecations
used by those functions, which makes it harder to spot warnings for
our own code base.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
The gnome-shell-calendar-server calls to refresh queries even when it
has no time range set, which results in:
a) waste of resources (for example after login),
b) many runtime warnings in the journalctl log, related to
incorrect time range being used.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/244
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
Otherwise UTC is used which results in a different interpretation of
floating time events. This then could lead to a mismatch with events
generated e_cal_client_generate_instances_sync() which always uses the
default timezone. Such a mismatch would then cause constant invalidation
and reloading.
https://bugzilla.gnome.org/show_bug.cgi?id=781950
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769074
In commit 7e0e224e0, when moving from e_cal_recur_generate_instances()
to e_cal_client_generate_instances(), the return value of the
ECalRecurInstanceFn callback was accidentally removed; add it
back.
https://bugzilla.gnome.org/show_bug.cgi?id=769156
Instead of querying the client for a list of objects and using
e_cal_recur_generate_instances() to get occurrences for each of
them, we can use e_cal_client_generate_instances_sync() which
combines the functionality of both functions. This doesn't only
save us some lines of code (yay!), but also gives us access to
the real recurrence ID of an event, so we can get rid of the hack
of faking one.
https://bugzilla.gnome.org/show_bug.cgi?id=748226
We use the triplet of source ID, UID and recurrence ID to create
an ID to unambiguously identify an event, which we use to implement
hiding dismissed events from the calendar. However we currently
try to fetch the recurrence ID from the objects returned by
e_cal_client_get_object_list_sync(), which are always the primary
events with no recurrence ID. Instead, we need a recurrence ID
associated with each occurrence.
https://bugzilla.gnome.org/show_bug.cgi?id=748226
Each event returned by GetEvents includes the (currently unused)
UID, which is not always enough to unambiguously identify an event
(different calendar sources, recurring events, ...).
As we will start using the property to record events that have been
dismissed and should be persistently hidden from the calendar, change
it to a truly unique ID.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded
timeout of 25 seconds, which is insufficient for starting up e-s-r
in certain setups. Avoid a timeout error by starting the service
manually with a longer timeout before hand.
Also demote the error to a warning + exit failure instead of
a crash, to avoid triggering abrt reports.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
