Re: Gnome 3 Extensions/Themes Website?

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 <olav vitters nl> wrote:
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 get
> 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 the
> 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 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 '' 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 (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 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.

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 on my GitHub page: Be warned, it's new and ugly. And I'm not quite used to Django yet.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]