GObject automatically notifies when passing
properties as part of g_object_new(). This
happens after the instance is created, thus
after constructed().
By passing G_PARAM_EXPLICIT_NOTIFY, we avoid
this behavior. However, we are still notifying
PROP_CONTEXT in GcalWindow. Removing this other
notify fixes the crashes related to GcalContext.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/417
Dazzle is very sensitive to returning empty search results,
and ends up flickering when we pass a search model that is
not yet populated.
Wait for a few results, or for 150ms, before returning the
model.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/468
Currently the label text is only updated when set_value is called and
the new value is different to the current value. So if a format callback
is configured after the GcalMultiChoice is created, this won't be
applied until the value is changed to something other than the default.
The problem in issue #100 is that the default value for "month" is
0=>January. gcal_date_chooser_init sets the format callback and then
calls gcal_multi_choice_set_value with value==0 which won't update the
label.
Fix by having gcal_multi_choice_set_format_callback update the label
text with the result of applying the format callback to the current
value.
Fixes#100
The return value is nullable, but gnome-calendar fails to check it.
Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().
We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().
Fixes#419
The method ask_recurrence_modification_type() currently
receives an ESource, and tried to fetch the ECalClient
from the ESource by using g_object_get_data().
However, since we moved to GcalCalendar, we do not set
this data field in ESource.
Receive a GcalCalendar instead, and use the appropriate
function gcal_calendar_get_client() instead.
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.
Fixes#423
GNOME Calendar needs to deal with two different
weekday ranges:
1. Sunday → 0 ... Saturday → 6
2. Monday → 1 ... Sunday → 7 (used by GDateTime)
When converting (2) into (1), the correct calculation
is `weekday % 7`.
However, gcal_date_time_get_start_of_week() was doing
`weekday - 1` instead.
Fix it and do the correct calculation instead.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/451
This was originally discovered and fixed by Milan Crha; I'm just
forward-porting his fix to the master branch. self->clients takes
ownership of this source but we don't currently have ownership here,
leading to a double free vulnerability.
Fixes#435
While deleting the calendar, we may run into a situation
where the GcalCalendar instance is destroyed before the
GcalManager:calendar-removed signal is emitted, causing
us to emit the signal with a destroyed object.
Prevent that by increasing the ref count before emiting
the signal.
The new discoverer is a vast improvement over the code
that use used to have here. Right now, we fail to use
Soup to detect the URL, and that's been reported multiple
times already.
Use the new web discoverer code, and adjust the UI to
match the new code. Namely, use a GtkPopover to show
the credentials widget.
Fixes#380
The new source discoverer is a complete overhaul of
the current code. It is async-only, correctly threaded,
and easier to maintain.
A major new feature of this web source discoverer is
that it now pings the server to see if the URL feeds
us back with an iCalendar file.
Furthermore, it continues to use E-D-S WebDAV discovery
functions as a fallback mechanism.
Fixes#380
Trying to use environment variables to guess the locale was a good
attempt, but this is tricky because they have to be looked up in a
certain order: first LC_ALL, then fallback to LC_TIME, and finally LANG,
which was missed here. This caused a huge warning spam on the year view
when only LANG is set, and usually only LANG should be set since the
other environment variables are usually used for temporary overrides.
Instead, query the locale using setlocale().
Also, don't assert if the locale is shorter than expected (missing
territory code) since there is at least one valid locale that does not
have any territory codes (Esperanto) and since it's programmer error to
assert when the application processes unexpected input like this.
Fixes#424
