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 689781 - Don't expose mode-specific extensions via ListExtensions
Don't expose mode-specific extensions via ListExtensions
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: extensions
3.7.x
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks: 685744
 
 
Reported: 2012-12-06 17:19 UTC by Debarshi Ray
Modified: 2021-07-05 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dbus: Don't expose mode-specific extensions via ListExtensions (1.41 KB, patch)
2012-12-06 17:21 UTC, Debarshi Ray
needs-work Details | Review

Description Debarshi Ray 2012-12-06 17:19:53 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.
Comment 1 Debarshi Ray 2012-12-06 17:21:27 UTC
Created attachment 230905 [details] [review]
dbus: Don't expose mode-specific extensions via ListExtensions
Comment 2 Jasper St. Pierre (not reading bugmail) 2012-12-06 18:33:06 UTC
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.
Comment 3 John Stowers 2012-12-06 20:17:33 UTC
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).
Comment 4 Jasper St. Pierre (not reading bugmail) 2012-12-06 20:28:15 UTC
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?
Comment 5 John Stowers 2012-12-06 21:04:51 UTC
(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.
Comment 6 Florian Müllner 2012-12-06 21:39:27 UTC
(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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-12-06 21:57:45 UTC
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.
Comment 8 Jeremy Bicha 2013-01-25 15:36:57 UTC
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?
Comment 9 Florian Müllner 2013-01-25 15:40:01 UTC
(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.
Comment 10 Owen Taylor 2013-10-07 15:44:49 UTC
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.
Comment 11 Florian Müllner 2017-11-25 06:29:36 UTC
-- 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.
Comment 12 Florian Müllner 2017-11-25 08:45:18 UTC
Sorry for the noise, I "found" a bug in the migration script:
https://gitlab.gnome.org/External/bugzilla-to-gitlab-migrator/issues/2
Comment 13 GNOME Infrastructure Team 2021-07-05 14:03:46 UTC
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.