GNOME 3.8 is right around the corner – we are working on the release candidate today. In 3.8, shell extensions get a lot more recognition; via the new Classic mode that is built with extensions.
But there’s a whole universe of interesting extensions out there on extensions.gnome.org beyond the ‘official’ ones. Unfortunately, many of them are not currently marked as compatible with 3.8. Now is the perfect time to test your extension and make sure it is ready for the new stable release.
It’s a shame the GS developers don’t commit to some kind of API stability then this wouldn’t be explicitly needed – or at least there should be a page which documents what has changed from say 3.6 -> 3.8 so extension developers can have some idea as to whether their extension is likely to be broken – if the GS team wants to encourage an extension ecosystem they should be willing to foster it with some kind of API stability guarantee. Anyway, off to see if the few extensions I’ve developed need any work under 3.8…
It’s a problem with man power, perhaps you could lend a hand?
Agree. Gnome Shell needs a stability of Extension API.
@Alex. Do you want world peace and an anti gracity device too? 🙂 What you ask is not so easy. When ever the shell has its source code changed it might be a problem for some extension. What is different this time is GNOME devs are communicating that shell is close to RC code freeze. Extension devs can now look at making old extensions ready for 3.8.
If you get in trouble just hit the shell mailing list. I will bet you get a friendly and useful advise.
I personally don’t think that Alex have said nothing wrong… API stabilization or blog post about changes would be really appreciated by me.
I created an extension that doesn’t work on GNOME 3.8. But given that there is no way to debug (there is no errors tab on the lg anymore), I’m not going to spend time on fixing it. I spend a lot of time upgrading it to GNOME 3.6 and now it doesn’t work again.
I don’t think this is good for gnome.
=The errors tab in Looking Glass was removed because it was confusing to our users — it only logged some of the errors. We’re looking for better ways to expose things to our users, but all JS errors are logged to stderr. It’s a bit unfortunate right now due to the state of distributions, but stderr is logged to one of three places:
~/.xsession-errors
~/.cache/gdm/session.log
The systemd journal (use journalctl to view messages)
Hopefully in the near-term when journalctl and systemd become more common, we can create better UIs to show you the structured error messages.
I’d at least like to be able to see the current status of extensions in relation to compatibility. There’s a few extensions I won’t do without (notably maximus) and I’ve held off upgrading to 3.8 because I can’t verify whether or not the extensions I use will continue to work unless I commit to the upgrade. extensions.gnome.org needs to show compatibility information.
I think Alex has nailed this on the head.
The major problem with GNOME is the lack of stable APIs. Ever changing interfaces, the 6 month release schedule. The fact that GNOME and Linux developers seem to mostly use Apple products, and then try to make GNOME into Mac OS X.
These are all big problems that no-one in GNOME seems to understand.
Right now I am on GNOME 3.6 and I can’t log out of my desktop to change user, nor can I suspend. These are GNOME extensions installed by extensions.gnome.org, which clearly do not even work for 3.6.