Re: Extensions Infrastructure Work

Thank you for the hard work you are providing. juste some first questions.

2011/6/21 Jasper St. Pierre <jstpierre mecheye net>
Hey guys, it's Jasper.

As part of my work on SweetTooth[0], I'm planning on a bunch of
changes to make the user experience for installing, enabling and
disabling extensions better. Unfortunately, I'm gonna have to break
some stuff unless someone can come up with a clever hack. These
changes are not set in stone, but they're what I'm hacking on
currently, and I'd like to discuss them to make sure I'm on the right
track. Extension developers, I'm talking to you:

 * I want live extension enabling and disabling. The user experience
is "click a button on, it takes effect

 * I want to make it safer and more usable for developers to import
code and assets their extension directory.

 * I want extensions to be smart about their dependencies. For
instance, the systemMonitor extension depends on an introspectable
GTop, which AFAIK is unreleased, and hasn't been packaged in F15. The
only clue users have that something has gone wrong is the Errors tab
in the LookingGlass.

Will it be needed to explicitly declare depedencies, or will it be automatic when importing?
can it be dependant on another one, to ensure that it is loaded after? (imagine an extension that requires theme to be enabled for exemple)


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?

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.


will the gnome extension infrastructure be officially supported by gnome-shell?

will there be a crypto system to sign your extensions to prevent them to be added from unrecognised sources?

will there be an automatic update infrastructure?

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