>>> Unfortunately, in order to do these things, I need your cooperation.
>>> I'm going to break some stuff, and I'd like your involvement so that I
>>> don't make a wrong decision which means another API break. I'd rather
>>> break it all at once and do things right.
>>>
>>> Let's tackle item 1:
>>>
>>> == Enabling and Disabling ==
>>>
>>> I'm going to remove the main() method, and replace it with a new system.
>>>
>>> You still require one function: init(). It does everything the main()
>>> function usually does, except it cannot change *any* Shell state. This
>>> is here so that you can set up anything you need to, like gettext
>>> silly shell actors. It's guaranteed to be called at most once per
>>> shell session.
>>>
>>
>> How does shell state modification will be prevented? i thought that it was
>> not possible to prevent code to mess with other shell part?
>> or did i missread you?
>
> I won't try to install code that prevents you from modifying the Shell
> init(). There's two other deterrents:
>
> One, I'm going on the nature that everybody will play nicely. What's
> the incentive for users to modify the Shell during init()?
>
> Two, if you don't do follow the rules, you won't pass review on the
> web-UI, which means you have to try harder for people to install your
> extension.
>
>>> So, what's used to change the Shell UI? We introduce two new methods:
>>> enable() and disable(). Here's some simple rules:
>>>
>>> * The Shell will call init(), and then enable() if your extension is
>>> enabled when the shell starts up.
>>>
>>> * The Shell may then call disable() and enable() again during the
>>> same session, but it should never call init() more than once, ever.
>>>
>>> * The Shell will not call disable() if your extension is disabled at
>>> startup.
>>>
>>> * Right now the Shell calls init() even for disabled extensions at
>>> startup, but I may change that so that it calls init(), then enable()
>>> at first enable. The simplest solution is to not rely on init() coming
>>> at the start of the Shell session.
>>>
>>> For those of you who would like something a bit more object-oriented,
>>> you're in luck: init() can also return a state object. All that
>>> requires is functions named "enable" and "disable" on that object, the
>>> type doesn't matter nor do any other fields. The shell won't touch
>>> that object except for calling 'enable()' or 'disable()' on it. If you
>>> don't return anything (or return a false-y object), it's assumed that
>>> enabl() and disable() are on the moduie itself. Here's a simple code
>>> example: For lack of better terms, I'm calling these extensions
>>> "stateful", and the module ones "stateless", even though that's a huge
>>> lie: both have state.
>>>
>>> Starting with an improved version of the stock "Hello, World!"
>>> extension in the old system[1], we can build a new extension in one of
>>> two ways:
>>>
>>> 1. We can simply rename the main() function to init(), and move the
>>> line of code that adds the actor to the Shell to a new enable()
>>> method, and add a disable() method that does the reverse.[2]
>>>
>>> 2. Or we can make the extension return an object that has enable()
>>> and disable() functions.[3]
>>>
>>> If you want your extension to be compatible for old versions of the
>>> shell, thankfully, it's very easy: just write a main() that calls
>>> init(), then enable(). For the extensions website, I may allow
>>> so-called "legacy" extensions with a special method that restarts the
>>> Shell, but it would break the user-experience a bit, and it's extra
>>> code that I don't think would get used.
>>>
>>> Checking out the code samples, you may notice an argument called
>>> "helper". That's a cliff-hanger for next time, when I want to talk
>>> about items 2 and 3. I'd like your feedback on the information I'd
>>> provided so far, and any questions on SweetTooth, the web site, or the
>>> modifications I'm making would be extremely appreciated.
>>>
>>> Jasper
>>>
>> will the gnome extension infrastructure be officially supported by
>> gnome-shell?
>
> Yes. There's no point if it isn't or won't.
>
>> will there be a crypto system to sign your extensions to prevent them to be
>> added from unrecognised sources?
>
> I discussed it with Owen, but I think we both think it's not
> necessary: as long as we make the automatic system only work from
>
extensions.gnome.org, we should be safe. I don't want to prevent users
> from installing random extensions, just make it harder: a rogue Shell
> extension can (unfortunately) do a lot more than a Firefox/Chrome one
> right now, so I doubt I'll be making exceptions to that rule until
> that changes. If the extension is not on
extensions.gnome.org, users
> can unpack the extensions and restart the shell manually.
>
>> will there be an automatic update infrastructure?
>
> Yes. The Shell saves a "manifest" for every extension it installs,
> which is basically the metadata.json that the user uploaded along with
> the extension zipfile, plus some other stuff. It includes the UUID,
> among other things. This means that it can automatically update if
> there is a newer version compatible with the shell version.
>
> Jasper
>
