Commit Graph

36 Commits

Author SHA1 Message Date
Evan Welsh
a88e59c1a8 Adopt EventEmitter class instead of injecting Signal methods
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.

EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.

The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
2022-07-04 18:30:49 -04:00
Florian Müllner
5442266f28 js: Simplify promisify() calls
If the finish function isn't specified, promisify will now try
to use the async name without '_async'/'_begin' suffix (if any)
and '_finish' appended.

Everything except IBus uses a variation of that pattern, so there's
quite a bit of boilerplate we get to remove…

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2174>
2022-02-11 16:24:01 +00:00
Florian Müllner
df76c3fd11 Update links to use HEAD instead of master
That way the link will keep working when projects change their
default branch name.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1914>
2021-07-18 21:45:46 +00:00
Georges Basile Stavracas Neto
c5e5514c51 weather: Pass providers after application-id and contact-info
It now requires both application-id and contact-info to properly
set the enabled providers.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1571>
2021-01-14 16:47:52 -03:00
Florian Müllner
d5ca1bc62f weather: Provide application-id and contact-info
Those are now required in order to use any online providers.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3577

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1565>
2021-01-13 21:03:35 +00:00
Florian Müllner
7458d5ad07 weather: Adjust to renamed provider
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3577

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1565>
2021-01-13 21:03:35 +00:00
Florian Müllner
42ce04b108 Revert "WeatherClient: Set enabled providers after setting a valid location"
libgweather changed to not do any implicit network traffic in property setters,
so this is again safe to pass to the constructor.

This reverts commit 73b7d9ace4.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3577

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1565>
2021-01-13 21:03:35 +00:00
Florian Müllner
764527c8c9 js: Promisify async operations
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.

gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.

Use that to get rid of all those GAsyncReadyCallbacks!

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
2020-03-31 05:43:40 +00:00
Florian Müllner
154655838d weather: Only require auto-location authorization if sandboxed
Since commit 87e60ed97843, geoclue no longer pretends that authorization
is useful for system-installed apps (as they can easily lie about their
ID). Unfortunately this broke our auto-location support in case Weather
is installed non-sandboxed, as we are waiting for an authorization that
will never happen.

Unbreak it by only requiring authorization when installed as Flatpak.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1823
2019-12-09 11:10:54 +00:00
Florian Müllner
e44adb92cf cleanup: Avoid unnecessary parentheses
Extra parentheses usually add noise rather than clarity, so avoid
them.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
ebf77748a8 cleanup: Require "dangling" commas
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
682bd7e97c cleanup: Don't shadow variables
Having variables that share the same name in overlapping scopes is
confusing and error-prone, and is best avoided.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Florian Müllner
ec6e1315a5 weather: Pick up original settings values
We mirror Weather's location settings to not depend on the app running,
but then don't read the original values, oops.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
2019-08-07 18:53:41 +00:00
Florian Müllner
ad55cb6d5d weather: Fix warning on closing Weather
GDBusProxy::g-properties-changed is also emitted when the name drops from
the bus, at which point any properties will be null. That's not a valid
gsettings value, so to avoid the corresponding warning, move the g-name-owner
check accordingly.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
2019-08-07 18:53:41 +00:00
Florian Müllner
02b47f4640 weather: Fix property name
It's g-*name*-owner. As the condition covers the unlikely case where
Weather is running before gnome-shell, this slipped through.
2019-08-01 01:50:13 +02:00
Florian Müllner
933c037c6e weather: Stop accessing app settings directly
Our current Weather integration depends on poking around the app's
settings, which we cannot do when the app is sandboxed (as its
filesystem is "hidden away" in a container in that case).

So instead, use our own GSettings schema for the settings, and sync
it with GNOME Weather via a custom D-Bus interface.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
2019-07-31 19:04:41 +00:00
Florian Müllner
71759a0769 cleanup: Mark unused (but useful) variables as ignored
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
2019-07-24 00:28:45 +02:00
Florian Müllner
0d035a4e53 cleanup: Prefer template strings
Template strings are much nicer than string concatenation, so use
them where possible; this excludes translatable strings and any
strings containing '/' (until we can depend on gettext >= 0.20[0]).

[0] https://savannah.gnu.org/bugs/?50920

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/612
2019-07-05 11:32:31 +00:00
Florian Müllner
14d7897a93 style: Stop using braces for single-line arrow functions
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.

We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.

So just omit braces consistently as mandated by gjs' coding style.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
2019-07-02 12:17:46 +00:00
Florian Müllner
f250643385 style: Use space after catch
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
2019-07-01 23:44:11 +02:00
Florian Müllner
fea0192772 weather: Handle missing permission store
Our weather integration is supposed to follow GNOME Weather's settings,
including its permission to use location services. However there's a
discrepancy in case xdg-desktop-portal is unavailable:

While our geoclue agent grants all applications access to location
services in that case, the weather integration treats it as if
access was denied.

Fix this by handling this case explicitly.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1130
2019-04-03 13:27:42 +00:00
Florian Müllner
fd50b9a45e cleanup: Use destructuring for imports from GI
This is *much* nicer than repetitive "imports.gi" lines ...

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/399
2019-02-09 07:39:20 +01:00
Christopher Davis
409a27c3b8 weather: Change Weather app ID
As of 9f7f5a68d4 Weather uses
org.gnome.Weather everywhere instead of org.gnome.Weather.Application.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/379
2019-01-31 12:33:10 -05:00
Florian Müllner
bacfdbbb03 cleanup: Port non-GObject classes to JS6 classes
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
2019-01-25 14:02:44 +00:00
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