GNOME Bugzilla – Bug 689781
Don't expose mode-specific extensions via ListExtensions
Last modified: 2021-07-05 14:03:46 UTC
Mode-specific extensions are an implementation detail and should not be exposed over D-Bus. Otherwise they will be exposed in gnome-tweak-tool.
Created attachment 230905 [details] [review] dbus: Don't expose mode-specific extensions via ListExtensions
Review of attachment 230905 [details] [review]: ::: js/ui/shellDBus.js @@ +256,2 @@ let out = {}; + for (let mode in SessionMode._modes) We shouldn't access private properties from methods.
I think this is a good idea, I'm not sure. I guess this lets e.g.o also ignore core extensions. Can you think of some future case where certain extensions might themselves offer other values to be tweaked? In that case I might want to test they are offered by a certain shell version and offer such tweaks if they are loaded. An alternative way to do this in tweak tool would be the shell to export another method ListCoreExtensions (and do the filtering on the g-t-t or e.g.o side).
I'm neutral on whether this is a good idea or not. This also has a disconnect with e.g. gnome-shell-extension-prefs, where you see a different class of extensions configured. Our main entry to configuration is the website, but I'm not sure that's appropriate for "system extensions", so we'd have to find another way to launch the prefs tool. Overall, I'm not a fan of the implementation. I'd prefer to see something on the extension object, maybe a third ExtensionType? We have SYSTEM and USER, so why not MODE?
(In reply to comment #4) > I'm neutral on whether this is a good idea or not. This also has a disconnect > with e.g. gnome-shell-extension-prefs, where you see a different class of > extensions configured. Our main entry to configuration is the website, but I'm > not sure that's appropriate for "system extensions", so we'd have to find > another way to launch the prefs tool. g-t-t can launch the prefs tool, but is the prefs tool appropriate for these MODE extensions (considering we are pushing advanced configuration into g-t-t) ? > > Overall, I'm not a fan of the implementation. I'd prefer to see something on > the extension object, maybe a third ExtensionType? We have SYSTEM and USER, so > why not MODE? Agree. I'm sure some autofoo magic could set the appropriate ExtensionType when building the gnome-shell-extensions.
(In reply to comment #5) > g-t-t can launch the prefs tool, but is the prefs tool appropriate for these > MODE extensions? Yes, I think it would be better in this case to have a more integrated way to present these settings. > > I'd prefer to see something on > > the extension object, maybe a third ExtensionType? We have SYSTEM and USER, so > > why not MODE? > > Agree. I'm sure some autofoo magic could set the appropriate ExtensionType when > building the gnome-shell-extensions. No, whether an extension should be visible should not depend on whether it is part of the core set, but how it is enabled, e.g. core extensions that are installed normally in the default session should not be treated differently from any other extensions. So the ExtensionType cannot be set at build time, but gnome-shell should do it at load time.
Extension types actually can't be at build-time, since they're current based on where they are in the system: in the system dir, or in the user dir. It at first might seem like a bit of a stretch to add a third type unrelated to this, but currently the distinction is used to ask questions like: "can I uninstall this extension? what about upgrading it?", so I think it makes a good fit. We should probably also return an error for "EnableExtension" / "DisableExtension" / whatever called on a MODE extension as well.
One possible way of thinking of Classic Mode is "training wheels" for regular GNOME Shell. In this view, users may want to enable some of the classic-mode extensions but disable others. For instance, what if I wanted regular GNOME Shell plus the alternate tab extension? What would be the workflow for me enabling this setup?
(In reply to comment #8) > For instance, what if I wanted regular GNOME Shell plus the alternate tab > extension? What would be the workflow for me enabling this setup? From the default GNOME session, go to extensions.gnome.org, search for "alternate tab" and enable it.
it seems better to me to return something like a modeEnabled=classic string to the "extension info" returned by list extensions, and then make the tweak tool and the web sight understand that. * So the web site doesn't think that these extensions can be installed but instead provides a on-and-disabled slider. * So the user is shown a meaningful message like "This extension is enabled as part of Classic Mode, which you are currently running." if they navigate to extension. (They see someone saying recommending Alternate Alt Tab for GNOME and linking to the extension.) * So that extension preferences for these extensions are available on the web site and through gnome-tweak-tool.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab-test.gnome.org/fmuellner/gnome-shell-extensions/issues/95.
Sorry for the noise, I "found" a bug in the migration script: https://gitlab.gnome.org/External/bugzilla-to-gitlab-migrator/issues/2
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.