At this point, I think we're going to try to make extensions more of a first-party thing than "gnome-tweak-tool". After several people have been making gnome-shell extensions and distros have been packaging them, I think we need to step in and do it "the right way" before we have situations where we conflict between distro packages.
1. I want to make installing and uninstalling (and enabling and disabling) extensions as painless as possible.
Unfortunately, I can't think of any good way at the technical level to do live extension disabling without requiring extension authors to keep track of it themselves, and I'm not sure we want to commit to an API like that yet. To do this automatically, If they add an actor to the top panel, we'd need to know and remove it when we disable the extension. When they modify a property, we need to undo that. And it gets complicated when multiple extension interact with each other: if extension A and extension B both tweak Foo._bar, and I enable extension A, then B, what do I do when I disable A? By putting it back to what it had before extension A had, I've unintentionally crippled extension B. Going forward, I think explicit hooks are the only way to do this system sanely. Until then, we need a sane way to restart the shell that doesn't take too long and doesn't go ugly when losing window decorations for a bit.
For the UI itself for enabling/disabling extensions, gnome-tweak-tool can certainly do it by itself, but I think a neat solution that Owen thought of would be to write an Epiphany extension that tweaks '
http://extensions.gnome.org' to have Enable/Disable buttons if you already have an extension there installed, as well as inserting a 'My Installed Extensions' link or button somewhere.
2. I want to make the user experience for a "rogue extension" better.
What happens if an extension crashes the shell unintentionally? There may be a distro patch to gnome-shell or the extension may be relying on a specific setup or file that doesn't exist on every machine. Right now we'd basically put up the fail whale and say "oops, try the fallback mode". Should the dialogue detect if you have extensions running and put up something saying "One of these extensions may be crashing the shell... do you want to try again with all extensions disabled?" Should we try to run again, and if it succeeds, put up a dialogue box explaining what happened.
Should we have a special gsettings key that mirrors Firefox's "extensions.checkCompatibiity"?
What should the developer experience be like? Should we require that developers have a BGO account so we can send them bugs? Should we send them an email with stack traces, or when a new comment comes in on their extension.
3. Developer Experience.
This is a point Company brought up last night on IRC. I want to make it painless for a developer to make an extension. I don't want random GNOME APIs crashing the shell (GSettings) from extension code. Company suggested that we could hack gobject-introspection to provide something akin to a "prerequisite check" with an annotation: if needs a valid D-Bus object path and will g_return_if_fail when it fails, we could add an annotation like
@object_path: (validation-check g_variant_is_object_path): An object path.
that would throw a JS error instead of crashing. If only we could just hack out all the asserts to throw JS errors instead...
Additionally, when the shell crashes, it's often annoying or hard to get back up and running: you lose your window decorations (and ability to interact with windows) and someone like me has to usually switch to a tty, fix my error in the poor environment of a tty (or try to remember what blacklist gsettings key you have to use to disable it) and then restart the shell. Not the best experience.
4. Security.
What happens if the extension is malicious? This is raw code that's running, it can do everything the shell has the ability to do: it can phone ~/.bash_history and ~/.recently-used back home. It can insert a Clutter event filter for keyboard events and get a free keylogger that doesn't require root access to install.
Right now, the best bet I have is having a small team reviewing gnome-shell extension code, with clear guidelines to reject or ask for clarification on any line of code that's confusing. We could consider forking the automatic validator in use for
addons.mozilla.org (or AMO):
https://github.com/mattbasta/amo-validator/
If we get closer to implementing concrete hooks like "Add this to the
top panel", stick to them, and disallow monkey patching, some of the issues here are resolved, but with the breadth of extensions that are out there (even one that adds tiling support!), I'm not sure this is a good idea.
