Commit Graph

23 Commits

Author SHA1 Message Date
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
Jasper St. Pierre
831099cca5 browser-plugin: Provide new APIs for launching extension preferences
Add two new APIs, "launchExtensionPrefs" to let SweetTooth let the user
launch the extension preferences tool directly from the browser. To allow
SweetTooth to check if an extension can be configured, add a new key to
the 'metadata', 'hasPrefs', which is returned by the GetExtensionInfo/
ListExtensions DBus methods.

https://bugzilla.gnome.org/show_bug.cgi?id=668429
2012-02-07 16:00:37 -05:00
Jasper St. Pierre
80ff6ff797 Move a lot of miscellaneous code related to extensions into a new module
ExtensionUtils is a new module that has a lot of miscellaneous things related
to loading extensions and the extension system put into a place that does not
depend on Shell or St.

Note that this will break extensions that have with multiple files by replacing
the old uuid-based importer with an object directly on the meta object.

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