On Wed, Jun 22, 2011 at 5:59 AM, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > On Tue, Jun 21, 2011 at 7:40 AM, Jasper St. Pierre > <jstpie...@mecheye.net> wrote: >> On Tue, Jun 21, 2011 at 6:54 AM, ecyrbe <ecy...@gmail.com> wrote: >>> Thank you for the hard work you are providing. juste some first questions. >>> >>> 2011/6/21 Jasper St. Pierre <jstpie...@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 extensions.gnome3.org, it takes effect >>>> immediately". >>>> >>>> * 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) >> >> Both of these are planned, but currently unimplemented, and I'm not >> comfortable telling people what it looks like when it's unimplemented. >> But my generic answers are "Yes" and "Yes". I'm unsure if I can do >> stuff to make PackageKit pop-up, or find the dependent extension >> install under the web-UI, we'll see. > > I must have been really tired last night, these answers are useless. > > Extension dependency management is tricky... first, for > auto-dependency-installation, they must be on the extensions web-site. > The harder part is versioning. > > Extensions will need to explicitly list their dependencies. I don't > know enough about PackageKit, but I'd like to say, "can you look for a > GTop.typelib anywhere for the correct architecture", and hopefully it > will work, even if the package puts it somewhere un-standard, but > that's Richard's question to answer.
Sorry if I'm late to the party with this suggestion, but I think this is where using zero install[0] for extensions would shine: - feeds that contain only JS (i.e no compilation required) are trivial to create. - built-in GPG signing of feeds - version requirements are supported for dependencies (before, not-before) - you can depend on other extensions, or on arbitrary packages. These can be other (vanilla) zero install feeds, or they can be feeds that are a wrapper for a system package - system packages can have multiple names for a given zero install feed. This will allow you to depend on fooBar for fedora, but libfoo-bar on debian - 0install uses packagekit to resolve & install system packages, so the experience should be fairly straightforward for users - doesn't require root access (unless system packages need installing, obviously) [0]: http://0install.net/ I'm working up to releasing an extension that requires my own mutter fork (for now, I hope that won't always be the case), and 0install is the only way I can sanely do so. It allows my extension to - have dependencies - not mess with the system version of mutter - work cross-platform (not a big deal when fedora is the only distro with GS, but will become more important later). I'd love 0install to be used for gnome-shell extensions, and I'm happy to help out with whatever I can to make that happen. > If it's not trivial, then nope, it's on the backburner for now. > >>>> 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 >> > _______________________________________________ > gnome-shell-list mailing list > gnome-shell-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
