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 NPAPI plugin shipped with the shell 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:

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.