Welp, I was going to have a thread announcing my work on this, but I guess
I'll just hijack this one.
First, one quick point out of the way: I don't think we need to separate
between themes and extensions. Going forward, I think that the user-theme
extension will die.
Hopefully, this horrible bug will be fixed:
, and then we can deploy
something clever Owen thought of: themes will be extensions like any other,
but with no code, and just a stylesheet. There will probably be a special
key in the metadata.json to tag it as a theme, so it can get loaded before
all the other extensions.
On Wed, Jun 8, 2011 at 4:31 AM, Olav Vitters
> On Wed, Jun 08, 2011 at 04:24:35AM -0400, Jasper St. Pierre wrote:
> > Right now I'm basically working on the upload interface: I'm trying to
> > it down to a simple "upload your extension tar.gz". There will be a
> > web-based form to edit any fields in it as well. I guess I can expose
> > same data from the XML in that format, but why?
> I imagine integrating such a extensions website with an application.
> Maybe within gnome-tweak-tool. For an application I think it would be
> nicer if the integration uses an existing standard (KDE uses it, so I've
> just assumed it is good enough:).
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
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
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
restart the shell that doesn't take too long and doesn't go ugly when
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
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
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
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.
What happens if the extension is malicious? This is raw code that's
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):
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
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.
I'm just wondering out loud though and hoping someone makes this happen ;-)
So am I. So am I.
P.S. you can find the code for the future http://extensions.gnome.org/ on my
GitHub page: http://github.com/magcius/sweettooth.
Be warned, it's new and
ugly. And I'm not quite used to Django yet.