Commit Graph

56 Commits

Author SHA1 Message Date
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