GNOME Bugzilla – Bug 621017
Add APIs for extensions
Last modified: 2011-10-03 16:49:38 UTC
GNOME Shell currently has a method for loading an additional user specified JS file, called an extension. Unfortunately, there is not much that file can do: - it cannot hook into the panel, as there is no public API for adding a menu item - it cannot add a button to the System Status area, as that is currently owned by private C code - it cannot add something to the Overview, as there is no public access to its parts That is, an extension, to be useful, must resort to private methods and properties inside Panel and Overview to display any useful UI. As I'm trying to develop a proof-of-concept nm-applet in JS, I may tweak my private Gnome Shell tree with the occasional public property, and I'm opening this bug to coordinate both on API and work. I will add a patch as soon as I have a decent one.
Hey, cool that you are planning to work on this! A couple of comments here. * If you are planning on any serious work here, you really should coordinate with Dan Williams. (dcbw on FreeNode IRC.) I've been talking with him on and off about how we want to do this over the last few months. There's a whole lot of logic in nm-applet we don't want multiple copies of, so various ways of trying to avoid rewriting all that logic in JS have been discussed. There are also mockups for how we want to do the user interface to integrate with GNOME Shell. * For GNOME 3.0 we aren't planning to have a stable API for extensions. (Inspired by Firefox, where they are just starting to make API guarantees for extensions now after many years of development.) Hopefully an extension will be a good way to prototype out something like this, but it's likely in we'd want to distribute a key piece like the networking system status indicator along with the Shell so that we can make sure it's up to date with any API changes. We're also not planning to have a separate API for extensions. Anything that is public inside the shell is fair game for extensions. Extensions, should not, however, in general, do things like accessing private _-prefixed members of objects. We do want to extend the shell's internal API to have the hooks and methods that extensions need. * For each API extension you need, please file a separate bug just for that one API extension. We really like bugs that we can close once they are fixed, not bugs that grow an ever-expanding list of new patches and new patch versions. git-bz makes it extremely fast to file a bug once you have a Git commit with the addition. (See http://live.gnome.org/GnomeShell/Development/WorkingWithPatches)
(In reply to comment #1) > Hey, cool that you are planning to work on this! Not planning - just trying to hack something and see how good it looks. > A couple of comments here. > > * If you are planning on any serious work here, you really should coordinate > with Dan Williams. (dcbw on FreeNode IRC.) I've been talking with him on and > off about how we want to do this over the last few months. > > There's a whole lot of logic in nm-applet we don't want multiple copies of, so > various ways of trying to avoid rewriting all that logic in JS have been > discussed. NetworkManager already has the necessary DBus stuff to talk to nm-applet (the user connection part), we just need to strip it off the GNOME2 applet (which would still be the Xfce / LXDE / everything else interface to NM). For the beginning, I was trying to get some ui while still having nm-applet running. > There are also mockups for how we want to do the user interface to integrate > with GNOME Shell. That's exactly what I am following. > * For GNOME 3.0 we aren't planning to have a stable API for extensions. > (Inspired by Firefox, where they are just starting to make API guarantees for > extensions now after many years of development.) Hopefully an extension will be > a good way to prototype out something like this, but it's likely in we'd want > to distribute a key piece like the networking system status indicator along > with the Shell so that we can make sure it's up to date with any API changes. 1) I'm not asking for a stable API (not until GS >= 1.0) - rather GS is missing any public API at all 2) Do you want to break every Docky, every WeirdClock, every FinanceApplet, every ComicView, every RandomHelloWorld, every WalkingSheep an user may have installed, in strange and hard-to-debug ways every time you fix a bug? Please no! 3) No you don't want to ship nm-applet with GnomeShell, cause not every user/distribution has NetworkManager. Some have wicd, some have ifup/ifdown, some pon/poff, some have strange distribution specific scripts (eg. Mandriva) Similarly, you want a keyboard layout selector - but you cannot have IBus on every machinge. That is, the System Status area should really be a container for distribution/system-specific *replaceable* components. > We're also not planning to have a separate API for extensions. Anything that is > public inside the shell is fair game for extensions. Extensions, should not, > however, in general, do things like accessing private _-prefixed members of > objects. We do want to extend the shell's internal API to have the hooks and > methods that extensions need. That's what I am asking for :) > * For each API extension you need, please file a separate bug just for that one > API extension. We really like bugs that we can close once they are fixed, not > bugs that grow an ever-expanding list of new patches and new patch versions. > git-bz makes it extremely fast to file a bug once you have a Git commit with > the addition. (See > http://live.gnome.org/GnomeShell/Development/WorkingWithPatches) Ok. I opened this bug so that you could track the others as depending on this, or something like that. In any case, if you prefer to have individual little bugs, just close this one.
(In reply to comment #2) > > 3) No you don't want to ship nm-applet with GnomeShell, cause not every > user/distribution has NetworkManager. I'm fine with just showing no networking UI if they don't. People who maintain other networking systems can feel free to step up and implement custom UI. An abstraction or generic interface over all of them is bound to fail. We can just have a reserved actor slot; Main.panel.networking_actor or something. > Similarly, you want a keyboard layout selector - but you cannot have IBus on > every machinge. > That is, the System Status area should really be a container for > distribution/system-specific *replaceable* components. To an extent. But on the other hand, those of us working on the shell are interested in making sure we interact well with best-of-breed FOSS projects such as NetworkManager, and to provide a compelling experience we need to cooperate on design.
Created attachment 178173 [details] [review] Load extensions before the status area is started Defer starting the status area until all extensions are loaded, so they can add themselves as status icons.
Created attachment 180344 [details] [review] ExtensionSystem: pass the metadata object to extensions This allows using metadata.json as a configuration point (for example for installation prefix).
Review of attachment 178173 [details] [review]: Don't see any reason why we shouldn't do this, if an extension wants to put stuff up there so let it do that.
Review of attachment 180344 [details] [review]: Looks good.
Comment on attachment 178173 [details] [review] Load extensions before the status area is started Attachment 178173 [details] pushed as 7810db6 - Load extensions before the status area is started
Comment on attachment 180344 [details] [review] ExtensionSystem: pass the metadata object to extensions Attachment 180344 [details] pushed as 6bf2dd9 - ExtensionSystem: pass the metadata object to extensions
Nothing more to be done here.