Sweet Tooth

SweetTooth is a project to help improve GNOME3 extension infrastructure, and to try to reshape the user and developer stories. The goals include:

Making it easy for users to find and install safe, approved extensions.
Make it easier for extension developers to build, test and distribute their extensions.
Start fleshing out a common extension API beyond what we have so far. This includes things like GSettings schemas for extensions,
- a hook or common monkey-patch API, as well a support for importing from other files in the same extension.
Make it clear that extensions are third-party, and not created or supported by GNOME.

These goals are realized by patches to GNOME Shell and the rest of the GNOME stack when necessary, as well as a new web-based tool inspired by web sites like addons.mozilla.org and the Android Marketplace.

Users

Users should be able to install and enable/disable extensions directly from the web UI. The way that this is done is with a custom browser extension (or deprecated NPAPI plugin shipped with the Shell before version 3.32) that exposes very basic DBus methods.

The fact that extensions are running arbitrary code makes it extremely difficult to do this without a centralized repository -- we want to secure the user and make it known that extensions in our repository are code reviewed to make sure they aren't malicious. Because of this, the automatic extension installation feature should only work on extensions.gnome.org. For extensions in other places, users will be required to download and unzip the files manually.

Commentary

Can us mere users also have the ability to easily configure extensions? The old method of editing a text file actually worked, whereas the current method, of finding a blog post on the topic and blindly copying and pasting something like "gsettings blah blah blah" is unsatisfactory for a number of reasons, not the least of which is that we often don't know what we just did, nor how to reverse it. Well commented text files promote understanding. It does seem that sometime gnome devs forget that users are not all devs. kurtdriver
That's up to the extensions, not me. All gsettings keys are documented in the schema, but for some reason the description isn't in the compiled schema, which makes it very useless. -- Jasper.

Reviewers

Reviewers review submitted extension code and make sure it does nothing malicious. Right now this is downloading a .zip file containing the extension and reviewing it, but Splinter may be integrated in the future.

The only reason an extension should ever be rejected is because of either malice or of sufficiently poor code quality where a blind look at the code can't determine whether it is malicious. Common judgment should be used. Reviewers are not allowed to reject extensions for brand or UX issues (e.g. "extensions aren't allowed to add to the top panel" is not a valid rejection).

Developers

Developers should be able to build, test, package and upload their extensions all from the command line. If their extension causes problems, gets rejected, or gets a low rating, the repository should email them with correct information and steps to take to resolve the issue.

Additionally, we should try to start making our libraries abort less. GSettings is the infamous example: we don't want a random extension developer to scratch his head, wondering why his extension makes the shell abort. While fixing the library should come first, we have several other options here:

Provide a thread-local GError that is set when an abort (g_assert, g_return_if_fail) happens, and allow language bindings like GJS to provide this useful information before failing.
Create a new annotation, (validity-check), that allows language bindings to make sure their arguments are valid beyond type information:

/**
 * g_dbus_connection_new_for_address:
 * @address: (validity-check g_dbus_is_address): A D-Bus address.
 * ...
 */

The function in (validity-check) would have to return a gboolean and take one argument -- the argument the annotation is specified. This allows some code like g_return_if_fail (g_dbus_is_address (address)); to not abort binding languages.

We can do the above, with a different approach. Instead of using a new annotation, instead define a new macro:

#define g_return_if_invalid(x) g_return_if_fail(x)

The gobject-introspection parser here could pick up these macros in the body of the function, and create automatic validity checks for them before calling the function. This means that we do validation for both introspected languages *and* C with very little effort (not that it required that much effort in the first place)

Unofficial Content

We want to portray through things like art and copytext on the web site itself that the extensions themselves are unsupported by GNOME itself. However, we need to ensure and portray three things:

The extension infrastructure itself is and needs to be supported. If users have a problem installing extensions, we've failed in some way, and need to fix it.
Using extensions should never feel shameful for the user: they should be branded and recognized as "things that can make your Shell personalized, cool and more featureful!" We cannot see them as hacks, workarounds, prototypes, or fallbacks but instead as pieces of functionality that users may enjoy using, sometimes even more than the GNOME UX. We cannot blame them for challenging "the divine GNOME UX, the holy and blessed way to do things," If users feel disappointed or frustrated that they have to install an extension, we've failed.
Extensions will not "void your warranty": we cannot close a bug report INVALID if the only evidence we have is the use of extensions. However, if an extension is found to *cause* the bug, we can close it and redirect them to the appropriate place to report a bug to the extension author.