Holding and releasing the weather service makes sure it
is stopped whenever no UI depends on it.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Splitting an activation flag from starting and stopping
the service makes it possible to flag the service as
wanted from the settings and still due use counting in a
subsequent commit.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
This helps in preparation of splitting out a dedicated
activation flag from the actually starting and stopping
the service.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
This is needed as the location service is not properly
stopped from the portal backend if running in a sandbox
otherwise.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
It's still a dependency through libgweather, but Calendar doesn't use it
directly. It looks like it was added for the weather feature, in a
function that ended up being removed.
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
