After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783103 - gnome-shell's enabled-extensions gsettings list is difficult for distros
gnome-shell's enabled-extensions gsettings list is difficult for distros
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: extensions
3.25.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-05-25 18:37 UTC by Jeremy Bicha
Modified: 2017-06-29 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeremy Bicha 2017-05-25 18:37:49 UTC
GNOME Shell extensions are enabled if they are listed in gsettings
org.gnome.shell enabled-extensions

1. This makes it difficult to handle upgrades if a distro wants to enable any extensions by default. (Just because a user enables a single extension does not mean that they intentionally want to opt out of having any other pre-enabled distro extensions when they upgrade their distro.)

2. This also causes a problem for certain extensions that should be enabled when installed. For instance, if you install gnome-shell-extension-onboard, it ought to be enabled without having to also explicitly turn it on. At least in Debian, it's expected that something usually starts working once you install it.

Proposals
---------
3. What about if the enabled key is part of the extension's own gsettings? Then a distro package could easily have the enabled key set or not.

4. And why not enable extensions by default? This would better match the behavior when you install extensions directly from https://extensions.gnome.org/
Comment 1 Jeremy Bicha 2017-05-25 18:41:25 UTC
See also bug 783104.
Comment 2 Florian Müllner 2017-05-26 00:09:25 UTC
(In reply to Jeremy Bicha from comment #0)
> At least in Debian, it's expected that something usually starts working once
> you install it.

Really? If some other user installs a particular GTK+ theme, I should expect *my* session to pick it up out of nowhere?

So no, this sounds like a terrible idea for system-wide installed extensions. For extensions that are installed in the user's home directory on the other hand, this behavior makes sense - and indeed if you install an extension that has "source: extensions.gnome.org" in gnome-software, this is how it works already.

I'm sorry, but I don't think the problem is that system-wide extensions work differently from per-user ones, it's that package managers are bad at handling anything but the former, yet distros keep packaging extensions that aren't used to customize the default session (or implement a different one) anyway.


> Proposals
> ---------
> 3. What about if the enabled key is part of the extension's own gsettings?
> Then a distro package could easily have the enabled key set or not.
> 
> 4. And why not enable extensions by default? This would better match the
> behavior when you install extensions directly from
> https://extensions.gnome.org/

No. Both proposals require that we recursively watch all extension directories to pick up newly installed extensions, and then load them automatically without knowing whether it was actually installed by the session owner. Or if we figure out a way to determine that, this would still not address the case where another user logs in a week later or so, and finds her session changed by someone else's actions. That sounds like a bug rather than a feature.

I agree that it's generally a better experience if extensions start working directly when installed, which is why we generally recommend to not install extensions from packages.
Comment 3 Ikey Doherty 2017-06-29 15:02:17 UTC
What if extensions instead ship with their own notion of "default-enabled", instead of being part of the main extensions key? Similar to how Rhythmbox is handling plugins that are vendor enabled