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 783104 - Not possible to disable individual Classic extensions in GNOME Classic
Not possible to disable individual Classic extensions in GNOME Classic
Status: RESOLVED NOTABUG
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:40 UTC by Jeremy Bicha
Modified: 2017-05-26 00:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeremy Bicha 2017-05-25 18:40:03 UTC
Install gnome-shell-extensions.
From the login screen, choose GNOME Classic and log in.

GNOME Classic enables several extensions, but it's not easily possible to individually disable specific extensions.

This is a problem if someone wants a hybrid experience that is closer to GNOME than pure GNOME Classic.

Also, there are some changes in GNOME Classic that are not easy to get in the regular GNOME session. For instance, it switches the theme to a lighter gray color.

I think GNOME Shell modes are an interesting idea. I considered using a GNOME Shell mode for Ubuntu's default session in case Ubuntu wants to enable at least one extension by default. But I think it's important that users can easily disable those extensions too.

See also bug 783103.
Comment 1 Florian Müllner 2017-05-26 00:09:18 UTC
(In reply to Jeremy Bicha from comment #0)
> GNOME Classic enables several extensions, but it's not easily possible to
> individually disable specific extensions.

That part of GNOME Classic is implemented via gnome-shell extensions really should be considered an implementation detail, similar to nautilus' desktop icons being enabled regardless of the show-desktop-icons setting. In both cases the session can provide a particular behavior because of the ability to sidestep the regular user settings. Adding another layer of settings on top to allow users to override the overridden setting again starts feeling like overkill.

IMHO it would be better to indicate that an extension was enabled by the mode, so our tools (website/tweak tool/extension-prefs) can show them as enabled-but-insensitive - see bug 689781.


> I think GNOME Shell modes are an interesting idea. I considered using a
> GNOME Shell mode for Ubuntu's default session in case Ubuntu wants to enable
> at least one extension by default. But I think it's important that users can
> easily disable those extensions too.

Yeah, if you want to enable a set of extensions by default, but allow users to disable them, then a session mode isn't the right tool. For what it's worth, that's what Fedora does with it's background-logo extension: It's installed by default and enabled by a GSettings vendor override.

It gets trickier if you want to enable those extensions on upgrade as well, but not impossible - you can install a session helper that gets run via /etc/xdg/autostart and does something like:

 schema=org.gnome.shell
 key=enabled-extensions
 gsettings set $schema $key "$(gsettings get $schema $key |\
                               sed 's:]:,"pinkify-desktop@distro.org"]:')"

That's hardly pretty, but arguably it's the wrong behavior anyway - in general I expect updates to preserve as many user settings as possible, not to change my wallpaper because the OS got a new default ...