Commit Graph

109 Commits

Author SHA1 Message Date
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
8a9e3e0df2 Switch string formatting to the one inside gjs
https://bugzilla.gnome.org/show_bug.cgi?id=675479
2012-05-24 15:38:44 -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
Owen W. Taylor
dd8a53d5e0 Revert "Fixed typo in string"
This reverts commit 44e02003ad.

The change:

 "GNOME Shell Extension Preferences" to "GNOME Shell Extensions Preferences"

was incorrect.
2012-02-22 18:52:08 -05:00
Giovanni Campagna
41f0e133a9 extension-prefs-tool: fix sensitivity of combobox items
Extensions are load asynchronously, and they're availability can
change at times, so sensitivity must sometimes be restored to true.

https://bugzilla.gnome.org/show_bug.cgi?id=670006
2012-02-13 19:29:42 +01:00
Daniel Mustieles
44e02003ad Fixed typo in string 2012-02-09 10:10:18 +01: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
b8a54faf94 Add a new tool, 'gnome-shell-extension-prefs', which can configure extensions
A new tool, 'gnome-shell-extension-prefs' can load a new entry point from
extensions, 'prefs.js', which has an entry point to return a GTK+ widget.
This allows extensions to have their own preferences dialog, without each
extension needing to ship its own Python script and .desktop file.

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