Speed up the gnome-shell animation speed
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 27 | Active |
| 26 | Active |
| 25 | Active |
| 24 | Active |
| 23 | Active |
| 22 | Active |
| 21 | Active |
| 20 | Active |
| 19 | Rejected |
| 18 | Active |
| 17 | Active |
| 16 | Active |
| 15 | Active |
| 14 | Active |
| 13 | Active |
| 12 | Active |
| 11 | Active |
| 10 | Active |
| 9 | Active |
| 8 | Active |
| 7 | Active |
| 6 | Active |
| 5 | Active |
| 4 | Active |
| 3 | Rejected |
| 2 | Inactive |
| 1 | Rejected |
Uh, why?
The previous version dies on an assertion (in Gio somewhere, I believe) if the schemas for SCHEMA_PATH are not installed and you try to access them, which is the case on gnome-shell 3.2. I assumed it would raise an exception, but it kills the shell dead instead :/ For distribution via 0install, I still want to allow the schema to be looked up on 3.2 (since the 0install feed installs the user schema correctly). That's why the getenvenv() check is there.
Whoops, I missed something -- you marking your extension compatible for GNOME 3.2. You can't do that if you want to use GSettings and want installation from SweetTooth. Consider hardcoding the preference value in the extension.js (allowing people to change it) for 3.2.
But the use of GSettings is protected by switches / exception catching, so it will gracefully fall back to the default (unconfigurable) value on 3.2 if installed via SweetTooth.
No try catch is going to protect you from an abort() in gio, unfortunately. Sorry, but we have to reject this, and deactivate all previous versions, until you remove GSettings usage or 3.2 compatibility.
Yeah, I discovered that the hard way ;) That's why (in v3), I've had to shield it in a check for getenv('GS_IMPATIENCE_SCHEMAS_INSTALLED') == 'true'. For SweetTooth installs, that effectively disables use of gsettings. I've tried this on 3.2, and it works fine. Do I really need to fork my source code so that there are no references to gsettings, even though they're unused?
What's going to set the envvar? I'd be fine with a imports.misc.config.PACKAGE_VERSION check, although gcampax may have a different take on that.
Nah, I'm ok with that too. Or even checking in Gio.Settings.list_schemas() and creating the object if find yours.
Zeroinstall will set the envvar, sweettooth will not. So that code won't be tried under sweettooth. The code in question is irrelevant for 3.4, as it will succeed on the local GSettingsSchemaSource code prior and never make it to this branch (so a version check here is unnecessary). A check for the individual schema would be better, but can we allow this version for the moment so that users of the broken version can upgrade?
Impatience