Commit Graph

12 Commits

Author SHA1 Message Date
Florian Müllner
3b1330880f cleanup: Use Function.prototype.bind()
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:55:02 +00:00
Florian Müllner
76f09b1e49 cleanup: Use method syntax
Modern javascript has a short-hand for function properties, embrace
it for better readability and to prepare for an eventual port to
ES6 classes.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:54:58 +00:00
Florian Müllner
033277b68f Define externally accessible contants with 'var' instead of 'const'
Just as we did with classes, define other constants that are (or
may be) used from other modules with 'var' to cut down on warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=785084
2017-07-18 21:52:06 +02:00
Florian Müllner
2582d16ca7 Define classes with 'var' instead of 'const'
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.

https://bugzilla.gnome.org/show_bug.cgi?id=785084
2017-07-18 21:52:06 +02:00
raresvis
8e443a2aff WeatherClient: set enabled providers after setting a valid location
So far, the GWeatherInfo was given the enabled weather providers
as a parameter, at construction time. Because of the way in
which libgweather was designed, setting the providers right from
the beginning enabled libgweather to use them internally in order
to update its state. Updating the internal state is only relevant
when there is a valid location set, which is not guaranteed at the
time when the GWeatherInfo object is constructed.

In order to fix this, enable no providers at construction time and
only set valid providers after setting a valid location.

https://bugzilla.gnome.org/show_bug.cgi?id=780404
2017-04-19 20:41:35 +03:00
Florian Müllner
c3428f1efa weather: Follow GNOME Weather's location permissions
Our weather integration should follow GNOME Weather as closely as
possible, which means that we should respect its location permission
rather than using our own or none at all (which we can as a "system"
component and as geoclue's authorization agent).

https://bugzilla.gnome.org/show_bug.cgi?id=780252
2017-03-20 19:13:20 +01:00
Florian Müllner
74e1058183 weather: Take global location switch into account
The setting to globally disable location settings altogether isn't
handled by the geoclue service itself, but by the authorization
agent. This means that:

 - it doesn't apply to system components
   (which gnome-shell is now considered[0])
 - it doesn't apply once the geoclue connection
   has been authorized

However users can reasonably expect that we won't use location services
after they disabled them, so handle the setting explicitly.

[0] https://cgit.freedesktop.org/geoclue/commit/?id=a4cef6c0ad08

https://bugzilla.gnome.org/show_bug.cgi?id=780252
2017-03-20 19:02:08 +01:00
Florian Müllner
7c9f76944b weather: Disentangle _useAutoLocation from Weather setting
We currently use automatic location for weather forecasts if the
corresponding Weather setting is set, however we should take other
factors into account as well:

 - whether location services are enabled at all
 - whether Weather has been authorized to use them

In preparation of these changes, track the setting's value in a
separate property and make _useAutoLocation a getter, so we can
extend it with additional conditions easily.

https://bugzilla.gnome.org/show_bug.cgi?id=780252
2017-03-20 19:02:08 +01:00
Florian Müllner
d393ca4f09 weather: Track whether a location was set
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.

https://bugzilla.gnome.org/show_bug.cgi?id=780252
2017-03-20 19:02:08 +01:00
Sebastian Keller
ce5875f365 weather: Handle GeoClue not responding
If GeoClue is not responding for some reason, the callback of
Geoclue.Simple.new would not get called, meaning that _gclueFailed
remains false. This is preventing the fallback to the most recently
used location in gnome-weather, because it requires _gclueFailed to be
true (or auto-location to be disabled). So neither code path sets a
location and the libgweather default (New York City) is being used
instead.

https://bugzilla.gnome.org/show_bug.cgi?id=779898
2017-03-11 20:53:11 +01:00
Florian Müllner
0e0caee6ba weather: Skip loading indication when updating frequently
Weather conditions - at least as far as online services are
concerned - don't usually change in a couple of minutes.
So when updating shortly after a previous update, assume
the current conditions are still valid and trigger an
update without showing a loading indication. This should
help a bit with not getting stuck permanently in loading
state when on a shitty network.

https://bugzilla.gnome.org/show_bug.cgi?id=754031
2017-03-01 10:52:43 +01:00
Florian Müllner
da831e894c weather: Add WeatherClient
In preparation of integrating GNOME Weather, add a helper class that
retrieves weather information according to Weather's configuration
if the application is installed.

https://bugzilla.gnome.org/show_bug.cgi?id=754031
2017-02-28 16:12:46 +01:00