The method currently catches errors that occur when calling the
extension's init() method, but throws itself an error if the
expected extension.js file is missing. The former is pointless
if we expect all callers to handle errors themselves anyway, and
we should avoid the latter if we don't - opt for the second option
and handle a missing extension.js file gracefully.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
While we catch errors that occur when calling init(), enable() or
disable(), the import itself can throw an exception, for instance
if the extension imports an unavailable typelib or tries to draw
in a conflicting library.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Both reloadExtensions() and enableExtensions() are already expected
to catch extension errors. If they don't, this is the bug that
should be fixed instead of catching unhandled exceptions in the
caller.
This reverts commit ff425d1db7.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Some extensions out there may fail to reload. When that happens,
we need to catch any exceptions so that we don't leave things in
a broken state that could lead to leaving extensions enabled in
the screen shield.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
When gnome-shell fails to start on login, gnome-session tries to
re-launch it again with all extensions disabled. This is currently
implemented by clearing the list of enabled extensions, which means
the user needs to re-enable their extensions manually again.
To make this process less annoying, add a single 'kill-switch' setting
gnome-session can use without interfering with the user setting.
https://bugzilla.gnome.org/show_bug.cgi?id=778664
Before reenabling all extensions, we update the list of enabled extensions
to catch any changes that happened while extensions were enabled. However
this is currently broken as onEnabledExtensionsChanged() is a nop while
disabled, so just call getEnabledExtensions() directly.
The current code only works for enabled extensions, which means
that extensions that were marked OUT_OF_DATE cannot be enabled
without a restart when disabling the version check.
Fix this by reloading all extensions while making sure to only
enable any extensions when we're supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
Add a key 'disable-extension-version-validation' key that disables
the validation of extension's claimed to be supported shell version
with the shell version and just load all extensions unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=724683
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.
As currently envisioned, the fallback replacement in 3.8 should be
a separate session at the login screen. As we will use extensions
to implement this mode, we need a way to specify extensions per
session rather than per user, so add a session-mode property for
extensions that should be loaded in addition to the user-defined
ones.
https://bugzilla.gnome.org/show_bug.cgi?id=689305
St.Theme.load_stylesheet() does not queue a theme context change, so
any styling of widgets created before will not be updated. To fix this,
load the stylesheet before the extension builds its own UI in enable()
https://bugzilla.gnome.org/show_bug.cgi?id=682128
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Use our native JS error system in the "extension system" API, only
using the signal/log-based error reporting at the last mile. Additionally,
delete the directory if loading the extension failed, and report the error
back over DBus.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Initially, extensions were loaded after they shell had fully created
the session and all objects, but this didn't allow extensions easy
ways to monkey patch prototypes, as most functions had already been
bound. Remove the historical vestigal function, and just merge the
two together.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
A large amount of extensions have something like this in them:
function init() {}
Since we have encouraged extension authors to try and not make any
changes in init, it feels weird and strange to have to create an
initialization function that does nothing. From now on, don't require
it.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
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
loadExtension() fails if the extension object is already created,
but the installation dialog was creating a dummy object in the
downloading state. Since nothing requires that (and the object is
not in the correct format anyway), just kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=671134
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
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
If an extension fails to import, we will pass the error object
to logExtensionError, which fails to pass it onto DBus as an
error object is not a string. To fix, convert the error object
to a string before passing it to logExtensionError.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
When installing an extension at runtime, we accidentally swapped the 'type'
and 'enabled' parameters. While this doesn't directly affect anything right
now, as everything works coincidentally, future patches that look at the
'type' parameter to decide what to do would get the wrong answer.
When two extensions monkey-patch the same area, enable() and disable() may
behave badly and completely wreck things. To solve this, when disabling
an extension, "rebase" the extension list so that monkey patches should be
added and removed in order.
https://bugzilla.gnome.org/show_bug.cgi?id=661815
Rather than loading and enabling all extensions at Shell init time, save some
time and gain some basic security by not loading extensions if they're
not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=661815
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
Pop up a dialog when trying to install an extension so that users are aware
they are installing one. This is a security precaution in the case that an XSS
exploit has been found on the website, which could cause someone to inject a
<script> tag and silently install an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
libsoup won't check for a valid cert by default, so copy some logic from
glib-networking to check against the system cert list. Additionally, allow a
fallback for developers, ~/.local/share/extensions.gnome.org.crt, for easy
local development of the website.
https://bugzilla.gnome.org/show_bug.cgi?id=658870
For those who like their system pure, this provides the ability to purge a
pesky extension and its precious place on your disk space, and in your
"Local Extension" list.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
Conflicts:
js/ui/extensionSystem.js
This adds a new DBus method: InstallExtensionRemote(uuid : s, url : s)
Pass it the UUID of an extension and the URL of a manifest file: the same as a
metadata.json, but with a special key, '__installer', which is an HTTP location
that points to an zip file containing the extension. The Shell will download
and use it to install the extension. In the future, the manifest file may be
used to automatically detect and install updates.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
The two similar keys were hard to manipulate to have specific effects, so just
remove one. Now there is an *explicit* whitelist: all extensions must be in the
'enabled-extensions' for them to be loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
Extension developers may be confused about why their extensions aren't working:
the LookingGlass isn't a very obvious place, or even which errors are theirs.
To remedy this, save all errors per-UUID which allows them to be retrieved
later.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
If the former is empty (default), only the extensions not contained in
the latter are loaded. Else, all extensions in the former that are
not contained in the latter are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=651088
Adding correct annotations to Gio.File.load_contents revealed that gjs
doesn't actually support array+length combinations. For 3.0 this would
be invasive to fix, so add a method to ShellGlobal which does what
we need.
https://bugzilla.gnome.org/show_bug.cgi?id=646333
Require that all extensions have a "shell-version" property in their
metadata, which is an array of supported Shell versions.
Extensions can target a specific version triple or an entire stable
version.
Optionally, they can also require a specific GJS version, to ensure
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=639255
Right now if XDG_DATA_DIRS is set to have duplicate entries,
then the extension system will try to load all extensions
more than once.
This commit prevents an extension from getting repeatedly
loaded by checking if its uuid is already registered.
https://bugzilla.gnome.org/show_bug.cgi?id=632477
Use GSettings for all Shell configuration. GConf is kept to read
configuration from external programs (Metacity, Nautilus and Magnifier),
but ShellGConf is removed because it's mostly useless for the few calls
we still have. Also get rid of unused GConf code in ShellAppSystem.
A basic GConf schema is still used to override Metacity defaults and
configure Magnifier in a system-wide fashion. GConf is also used as
GSettings backend via the GSETTINGS_BACKEND environment variable.
All of this will be removed when these programs have been ported
to GSettings and able to use dconf.
GLib 2.25.9 is required. Schemas are converted to the new XML format,
and compiled at build time in data/ so that the Shell can be run from
the source tree. This also requires setting the GSETTINGS_SCHEMA_DIR
environment variable both when running installed or from source tree,
in src/gnome-shell.in and src/gnome-shell-clock-preferences.in.
https://bugzilla.gnome.org/show_bug.cgi?id=617917
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
While the extension system already uses an XDG location (XDG_CONFIG_HOME),
other components use the deprecated $HOME/.gnome2 directory.
Replace both with XDG_DATA_HOME - the existing data (app usage stats,
looking glass history and extensions) is not migrated to the new location.
https://bugzilla.gnome.org/show_bug.cgi?id=617555
Consumer documentation will live at http://live.gnome.org/GnomeShell/Extensions
In terms of implementation; basically we load extensions from the well-known
directories. Add a GConf key to disable extensions by uuid. There is a new
option --create-extension for the gnome-shell script which takes a bit of
interactive input, sets up some sample files, and launches gedit.
No extensions UI in this patch; that will come later.
https://bugzilla.gnome.org/show_bug.cgi?id=599661
