Commit Graph

52 Commits

Author SHA1 Message Date
Florian Müllner
b54111ef88 cleanup: Use logical assignments
gjs updated mozjs to a version that support assignment operators
for logical operators, so use those where appropriate.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2115>
2022-01-25 15:21:16 +00:00
Florian Müllner
1deb13e1aa extensionUtils: Add gettext convenience helpers
We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.

Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.

Instead, extensions have to use domain-specific versions
of the gettext functions:

```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```

Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
2021-08-14 18:45:25 +00:00
Florian Müllner
95806c6a58 extensionUtils: Simplify version check
When adapting the check to the new versioning check, we just blindly
copied the old behavior for stable/unstable versions:

 - stable releases must have matching major numbers
 - unstable releases must match major and minor ("alpha", "beta", "rc")

That worked for the old even/odd scheme, but now has the absurd effect
that we consider an extension that lists "40.alpha" in its shell-version
incompatible with "40.beta", but compatible with "40.2".

At least this provides us with a good opportunity to reconsider the
behavior. While it is true that breakage is much more likely between
unstable releases, in practice extensions are either following shell
development closely or update once around the time of a stable release.

For the former, the stricter check isn't usually too useful (as the
extension releases around the same time as gnome-shell anyway).

For the latter, it's annoying that ".rc" is treated differently from
".0" and requires an update to become compatible.

The latter is also by far the more common case, so update the check
to only match on the major version regardless of whether a release
is stable or unstable.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1719>
2021-02-26 23:06:40 +01:00
Florian Müllner
7521b9c4b2 extensionUtils: Stop using Lang.copyProperties()
It is now deprecated, so use object destructuring instead.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1498
2020-11-16 18:04:23 +00:00
Florian Müllner
6b1e2df589 extensionUtils: Adjust version check
With the new versioning scheme, the previously-minor version gets
shifted up to major, and unstable releases are marked by non-numeric
"versions" rather than uneven numbers. Reflect that in the extension
version check.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1456
2020-10-06 15:06:09 +02:00
Florian Müllner
8030d9ad32 extensionUtils: Add openPrefs() convenience method
Opening their own preferences is a reasonable desire for extensions,
so make up for breaking it by adding a convenience method for that
action.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
2020-04-03 15:27:37 +02:00
Florian Müllner
375d1892bf extensionSystem: Add hasUpdate state
The current support for extension updates is half-baked at best.
We are about to change that, and implement offline updates similar
to gnome-software.

As a first step, add a hasUpdate property to the extension state
which will communicate available updates.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
2020-01-30 13:37:47 +00:00
Florian Müllner
2842670082 cleanup: Remove another pair of unneeded parentheses
Eslint didn't spot this before version 6.5, so this fell through
the cracks.
2019-11-23 01:29:20 +01:00
Florian Müllner
61210fdae1 cleanup: Use JSDoc for documentation comments
It's a better fit than gtk-doc, and eslint can validate that they
are complete and use correct syntax.

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
07cc84f632 cleanup: Only omit braces for single-line blocks
Braces can be avoided when a block consists of a single statement,
but readability suffers when the statement spans more than a single
line.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
2019-11-11 19:25:14 +00:00
Jonas Dreßler
8754736fda extensionUtils: Check version variable for undefined first
Avoid a warning message when trying to access requiredArray[2] by
checking if its undefined first.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
2019-09-12 10:24:49 +00:00
Florian Müllner
e357559582 cleanup: Mark globals used from other modules as exported
eslint cannot figure out that those symbols are used from other modules
via imports, so they trigger unused-variable errors. To fix, explicitly
mark those symbols as exported.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
2019-07-24 00:28:45 +02:00
Florian Müllner
43cb3754d9 extensionSystem: Store extensions in a Map
After making the extensions map private to the ExtensionManager, we can
switch it to a proper hash table which is more appropriate.

https://bugzilla.gnome.org/show_bug.cgi?id=789852
2019-07-20 14:17:35 +00:00
Florian Müllner
1d6ddf060b extensionSystem: Move extension loading into ExtensionManager
Now that extension loading and the extensions map are no longer shared
between the gnome-shell and gnome-shell-extension-prefs processes, we
can move both into the ExtensionManager which makes much more sense
conceptually.

https://bugzilla.gnome.org/show_bug.cgi?id=789852
2019-07-20 14:17:35 +00:00
Didier Roche
4a3476266f extensionSystem: Add canChange property to extensions
Whether or not an extension can be enabled/disabled depends on various
factors: Whether the extension is in error state, whether user extensions
are disabled and whether the underlying GSettings keys are writable.

This is complex enough to share the logic, so add it to the extension
properties that are exposed over D-Bus.

https://bugzilla.gnome.org/show_bug.cgi?id=789852
2019-07-20 14:17:35 +00:00
Didier Roche
58806359ee extensionUtils: Add functions to (de)serialize extensions
Serializing an extension for sending over D-Bus is currently done by the
appropriate D-Bus method implementations. Split out the code as utility
function and add a corresponding deserialization function, which we will
soon use when consuming the D-Bus extension API from the extension-prefs
tool.

https://bugzilla.gnome.org/show_bug.cgi?id=789852
2019-07-20 14:17:35 +00:00
Florian Müllner
d82810240f extensionUtils: Move ExtensionState definition here
It makes sense to keep extension-related enums in the same module instead
of spreading them between ExtensionSystem and ExtensionUtils.

More importantly, this will make the type available to the extensions-prefs
tool (which runs in a different process and therefore only has access to
a limited set of modules).

https://bugzilla.gnome.org/show_bug.cgi?id=789852
2019-07-20 14:17:35 +00: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
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
e56d7f5021 cleanup: Remove unused variables
Spotted by eslint.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
2019-07-01 23:44:10 +02:00
Florian Müllner
f6b4b96737 cleanup: Use Array.includes() to check for element existence
We can use that newer method where we don't care about the actual position
of an element inside the array.

(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
2019-07-01 21:28:52 +00:00
Florian Müllner
93425b0500 extensionUtils: Include some more helper functions
Those functions originated in gnome-shell-extension's Convenience
module which is copied by almost every extension out there. Let's
make people's life just a little bit easier by including the code
ourselves.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/150
2019-02-06 19:52:21 +01: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
7ca418a79a Explicitly convert raw data to strings
As strings are guaranteed to use UTF-8 in the GNOME platform, generic
file APIs like g_file_load_contents() return raw data instead. Since
gjs' recent update to mozjs60, this data is now returns as Uint8Array
which cannot simply be treated as string - its toString() method boils
down to arr.join(',') - so use gjs' new ByteArray module to explicitly
convert the data.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/179
2018-07-31 16:28:53 +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
Florian Müllner
d769b72c43 extensionUtils: Use a unique 'subdir' to create new importers
Apparently importers for the 'same' path are shared, even when the
relative paths resolve to different absolute ones. Until this bug
is fixed properly, we can work around this by expressing the current
extension path as the UUID relative to the parent directory.

https://bugzilla.gnome.org/show_bug.cgi?id=772386
2016-10-18 19:19:32 +02:00
Philip Chimento
ed99bef458 extensionUtils: Remove ShellJS library
You can define a new importer object by importing a subdirectory in GJS.
This is undocumented, but it is likely to at least hold until the whole
thing moves to ES6 modules, after which we'll be able to do this purely
in JS with Reflect.Loader.

Since this was the only thing the ShellJS library did, we can remove it
altogether.

This allows us to discontinue use of the gjs-internals-1.0 embedder API.

https://bugzilla.gnome.org/show_bug.cgi?id=772386
2016-10-17 12:36:16 -07:00
Jonh Wendell
c405081d89 extensionUtils: Allow getCurrentExtension() to be called from anyone
Currently it's assumed only an extension can call this method. However
it can be useful if any part of the shell want to know if it was invoked
by an extension.

https://bugzilla.gnome.org/show_bug.cgi?id=770717
2016-10-11 10:14:23 -03:00
Florian Müllner
b29e8a1a3d Fix typo 2014-12-11 15:48:51 +01:00
Jasper St. Pierre
da4238ec68 Synchronize shell startup
The asynchronous nature of extension loading, session loading, and more,
makes the code racy as to what is initialized first, and hard to debug.
Additionally, since gjs is single-threaded, the only code we're running
in a thread anyway is readdir, which is going to be I/O bound, so the
code here is actually likely to be faster.

Drop this in favor of some good old fashioned synchronous loading.
2013-11-04 11:50:20 -05:00
Florian Müllner
e99d69b7d9 extensionUtil: Add ExtensionFinder::extensions-loaded signal
Consumers might want to defer work until the initial loading of
extensions has finished, so add an appropriate signal.

https://bugzilla.gnome.org/show_bug.cgi?id=694858
2013-02-28 15:37:28 +01:00
Jasper St. Pierre
783abd4f5f Reverting "extensionUtils: Remove unused property"
This reverts commit 28aa9201f0.

This broke the extension-state-changed signal.

https://bugzilla.gnome.org/show_bug.cgi?id=690173
2012-12-13 14:16:44 -05:00
Florian Müllner
28aa9201f0 extensionUtils: Remove unused property
https://bugzilla.gnome.org/show_bug.cgi?id=690173
2012-12-13 19:55:34 +01:00
Florian Müllner
6b40c3974d extensionUtils: Load extensions asynchronously
Use the new collectFromDatadirsAsync() function for extension
loading as well.

https://bugzilla.gnome.org/show_bug.cgi?id=689304
2012-12-05 21:56:21 +01:00
Adel Gadllah
6dab119650 extensionUtils: Don't warn about missing url
This did not have the desired effect and just produces noise.
2012-10-05 20:35:07 +02:00
Owen W. Taylor
9395f310d6 extensionUtils: don't log verbosely on missing extension directory
A missing extension directory isn't worth debug spew, so check
if the error when reading the extension directory is NOT_FOUND,
and if so, suppress output.

https://bugzilla.gnome.org/show_bug.cgi?id=685466
2012-10-05 13:08:02 -04:00
Jasper St. Pierre
1363d30f79 extensionUtils: Don't crash on startup for an empty directory
https://bugzilla.gnome.org/show_bug.cgi?id=679099
2012-07-10 14:36:41 -04:00
Jasper St. Pierre
86de6f5861 extensionUtils: Create and load the extension object when scanning
This reduces some duplicate code when loading extensions.

https://bugzilla.gnome.org/show_bug.cgi?id=677586
2012-06-12 17:16:08 -04:00
Jasper St. Pierre
498b023989 extensionUtils: Use signals rather than callbacks for finding extensions
This allows us to move to a file-monitor based approach in the future.

Since we need signals, we convert the current set of functions to an
object we attach signals too, leading to the new ExtensionFinder object.

https://bugzilla.gnome.org/show_bug.cgi?id=677586
2012-06-12 17:16:08 -04:00
Jasper St. Pierre
5265884af9 extensionUtils: Remove userExtensionsDir
Make this less stateful

https://bugzilla.gnome.org/show_bug.cgi?id=677586
2012-06-12 17:16:08 -04:00
Jasper St. Pierre
cdbe0bbf38 extensionUtils: Remove version check for js-version
This is seldomly used, and isn't checked in SweetTooth. Just remove
this inconsistency here rather than adding infrastructure to manage
and check it elsewhere.

https://bugzilla.gnome.org/show_bug.cgi?id=677586
2012-06-12 17:16:08 -04:00
Jasper St. Pierre
feef35a8ca extensionUtils: Don't write to the filesystem on start
Create the potentially empty directory when we need to, not when we
don't.

https://bugzilla.gnome.org/show_bug.cgi?id=677586
2012-06-12 17:16:08 -04:00
Jasper St. Pierre
65d23fb9a3 extensionUtils: Support subdirectories in getCurrentExtension
Some extensions may have complex layouts with multiple subdirectories.
Currently, getCurrentExtension doesn't support this, as it uses a regex
and assume's that the last path's component's parent is all that's needed.
Fix this.

https://bugzilla.gnome.org/show_bug.cgi?id=677001
2012-05-29 14:36:16 -04:00
Jasper St. Pierre
ce041a3190 js: Don't use global.log*
These are "deprecated", and are just references to the gjs logging functoins

https://bugzilla.gnome.org/show_bug.cgi?id=675790
2012-05-18 14:09:00 -04:00
Jasper St. Pierre
5ea5806730 extensionUtils: Load user extensions before system extensions
https://bugzilla.gnome.org/show_bug.cgi?id=673613
2012-04-09 14:02:31 -03:00
Jasper St. Pierre
a622aba7eb extensionUtils: Create and allow access to a new "extension" object
The "extension" object is what I previously called the "helper" object.
It contains the extension importer object as well as the metadata object.
Things that were previously added on to the metadata (state, path, dir, etc.)
are now part of this new "extension" object.

With the new importer changes brought on by the extension prefs tool,
extensions are left without a way to import submodules at the global scope,
which would make them rely on techniques like:

  var MySubModule;

  function init(meta) {
      MySubModule = meta.importer.mySubModule;
  }

That is, there's now a lot more meaningless boilerplate that nobody wants
to write and nobody wants to reivew.

Let's solve this with a few clever hacks.
Allow extensions to get their current extension object with:

  let extension = imports.misc.extensionUtils.getCurrentExtension();

As such, extensions can now get their own extension object before the
'init' method is called, so they can import submodules or do other things
at the module scope:

  const MySubModule = extension.imports.mySubModule;
  const dataPath = GLib.build_filenamev([extension.path, 'awesome-data.json']);

https://bugzilla.gnome.org/show_bug.cgi?id=668429
2012-02-07 16:00:37 -05:00