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. 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
