gnome-shell/js
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
..
extensionPrefs extensionUtils: Create and allow access to a new "extension" object 2012-02-07 16:00:37 -05:00
gdm Fix some fallout from background-size addition 2012-01-10 21:50:21 +01:00
misc extensionUtils: Create and allow access to a new "extension" object 2012-02-07 16:00:37 -05:00
perf *.js: Make emacs modelines consistent 2011-10-11 08:05:12 -04:00
ui extensionUtils: Create and allow access to a new "extension" object 2012-02-07 16:00:37 -05:00
Makefile.am Add a new tool, 'gnome-shell-extension-prefs', which can configure extensions 2012-02-07 16:00:37 -05:00