GClue automatically calls the portal for us when sandboxed and in such case
a NULL is returned for the client porxy because the calls goes through the portal.
Part of https://gitlab.gnome.org/GNOME/Initiatives/-/issues/30
Currently, GNOME Calendar does not set up the contact_info needed in
libgweather 40 API. This leads to the following assertion, and no
weather forecast info being shown in Calendar:
`gweather_info_update: assertion 'info->contact_info != NULL' failed.`
To fix the assertion, set the URL to the DOAP file on the master branch.
GNOME Weather does the same, see:
https://gitlab.gnome.org/GNOME/gnome-weather/-/commit/6763f7dc9cb25eac4aa13e94e07ea932a42c8e4d
Part of #682
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
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
We fail to disconnect from the GWeatherInfo in both update_location()
and dispose. We have to fix update_location() manually. To avoid the
need to disconnect in dispose, we can just use g_signal_connect_object().
This commit brings a few changes that I was too lazy to
split in different commits:
* Remove a few useless arguments in the GcalWeatherService API
* Move the weather management code from GcalWindow to GcalWeatherSettings
* A few style changes
