GNOME Bugzilla – Bug 772576
Add extension support
Last modified: 2018-01-24 17:17:59 UTC
Very soon (maybe this year) the extension management plugin for Firefox will be broken since the xul plugin support will be gone. During GUADEC we decided on following course of action: Add support for extensions in gnome-shell insofar that we add a custom uri handler so that gnome-software can be opened by browsing extensions.gnome.org. Gnome-software can then be used to install/uninstall (configure?) extensions. Listing the installed extensions would be useful as well. Using the uri handler allows us to do without extension browsing in gnome-software, if this is too much work. I don't know what name for the handler would be best.
gnome-software already allows to install/update/remove of extensions. https://git.gnome.org/browse/gnome-software/tree/src/plugins/gs-plugin-shell-extensions.c The part is missing is for a user, using a broeser, to scan extensions.gnome.org and from there initiate the installation/configuration/removal - that would be the uri handler part mentioned in comment #0 as 'the only missing piece' (with a good UI / User story behind)
Why do we need to use a browser? I think doing the search/install/removal all in the gnome-software process keeps things much cleaner.
Extensions.gnome.org isn't going away since it is used for developers to upload their extensions. Every extension also has a homepage there, where developers point their users to. This is an established process and we should leave a way for users to browse and (via proxy) "install" extensions from this central repository that isn't going away. If e.g.o becomes obsolete insofar that it can not be used to affect any change in the system (in the losest sense, opening gnome-software with the correct extension selected is also "affected"), we need to communicate this to extension developers who are all pointing their users (from the github-repositories or blog-entries or whatnot) to e.g.o. Adding the uri-handler is the smallest problem here. Fundamentally changing the way the users interact with extensions without a heads up is what I want to prevent. Let's not make e.g.o to an extension-upload-form only, which it would basically become.
(In reply to Mario Wenzel from comment #3) > If e.g.o becomes obsolete insofar that it can not be used to affect any > change in the system With the loss of npapi, this is what's happening. > (in the losest sense, opening gnome-software with the > correct extension selected is also "affected"), we need to communicate this > to extension developers who are all pointing their users (from the > github-repositories or blog-entries or whatnot) to e.g.o. Right, that's probably something to bring up with the desktop-devel mailing list. > Adding the uri-handler is the smallest problem here. Couldn't an existing appstream:// url work here? > Fundamentally changing > the way the users interact with extensions without a heads up is what I want > to prevent. Let's not make e.g.o to an extension-upload-form only, which it > would basically become. We've got a decentralized general purpose review system in the ORDS, so what's the real problem in making e.g.o a developer upload platform?
> Right, that's probably something to bring up with the desktop-devel mailing list. Again, I don't believe we're really good at reaching out to the people that are affected, making a change that has fewer impact preferable. > Couldn't an existing appstream:// url work here? Don't the extensions then need to support it or can we supplement this data from the extension.js-file? I would be fine with any uri-handler that we can call from e.g.o. During guadec we talked about a different handler but either would be fine. > what's the real problem in making e.g.o a developer upload platform? Changing the established workflow in a major way where it is not strictly necessary. Every blog post, every developer points at e.g.o. Every promotion GNOME gets via an extension. Here is an example of an extension (one of mine) getting mentioned on omgubuntu linking directly to e.g.o: http://www.omgubuntu.co.uk/2016/08/notification-twitch-channels-go-live-linux-desktop I think we want users reading that page (for example) being able to click the link and reach a page that is somewhat actionable. Being able to open gnome-software via the extension page would be really good and easy at this point, instead of entering the extension name in the software management suite.
Firefox support will be added to chrome-gnome-shell [1] as soon as Mozilla will implement missing WebExtensions API call [2]. I hope this will happens before Firefox 52, so users will be able to migrate. Currently, chrome-gnome-shell supports Chrome/Chromium, Vivaldi and Opera. [1] https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1258360#c12
I don't think using the GNOME Shell Extensions website and using GNOME Software are mutually exclusive. Both solutions support discovering and installing Shell extensions from different contexts. The web version means that bloggers or people communicating via chat applications can recommend an extension and then link directly to it. On the other hand, GNOME Software is the natural place for users who want *something* that will let them accomplish X. So they could launch Software, search for X, and then find and install a Shell extension that does what they want. So, there's no reason we can't have both (unless that increases the cost of maintenance too much).
> I don't think using the GNOME Shell Extensions website and using GNOME Software are mutually exclusive. Both solutions support discovering and installing Shell extensions from different contexts. Agreed > Firefox support will be added to chrome-gnome-shell FYI it's done. Currently, Firefox extensions is on review by Mozilla staff. GNOME bug report: https://bugzilla.gnome.org/show_bug.cgi?id=754316
-- 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.gnome.org/GNOME/gnome-software/issues/99.