GNOME Shell and system extensions being part of a mode

[Didier Roche <didrocks ubuntu com>]

I want to propose some thoughts and potential rework around system 
extensions which are part of a mode towards update & QA process.
In ubuntu, we implement an "ubuntu" GNOME Shell mode which enables some 
extensions by default ("ubuntu-dock" and "ubuntu-appindicator"). Those 
are respectively an ID rename of dash to dock (with different defaults 
for that one) and KStatusNotifier extensions, installed as system 
extensions in /usr/share/gnome-shell/extensions.

Why did we do that?

Once we release an ubuntu version, anything part of the distributions 
receives bug fixes only, but no behavior or new defaults are allowed for 
UI and behavior stability are permitted (apart from browsers, having 
exception).
Consequentely, if our extension kept the same GNOME Shell extension ID 
than Dash to Dock, it would mean that any users can upgrade it as soon a 
new release of Dash to Dock reached the GNOME Shell extensions website. 
This would bypass all our QA & security procedures and checks (Ubuntu 
Desktop is supporting it and you have regular bug fixes and security 
updates) by enabling another source of update. Once people update from 
the website, it’s in their local user directory and no system update can 
override this, potentially having a stalled version they installed, or 
potentially a newer, incompatible version.
An online extension without multiple versions tracking doesn’t allow us 
to control that.

I guess RHEL should a similar problem shipping gnome-classic by default, 
made of system extensions, which can be equally overriden by user's 
update (or even be prompted to upgrade via GNOME Software!) and 
bypassing QA, security and such.

We workarounded it in Ubuntu 17.10 by not shipping those extensions 
(having little value compared to upstream dash to dock or 
KStatusNotifier one) on extensions.gnome.org. However, it means that 
anyone could upload a version and own our ubuntu systems. Discussion 
with the extensions website team is on the way to prevent that by either 
updating an empty extension that we never update (suboptimal) or 
preventing upload to our namespace.

Also, the support for system extensions is quite sparse: the "State" 
object in GNOME Shell is a mix of status, availability and error (See 
https://git.gnome.org/browse/gnome-shell/tree/js/ui/extensionSystem.js#n13), 
and miss some properties like "it's a system extension part of a mode". 
The consequence is that GNOME Tweaks/gnome-shell-extension-prefs are 
mostly reporting incorrect status being based on the API or gsettings 
enabled-extensions key: You are presented with a switch stating the 
extension part of a mode isn't enabled, and enabling/disabling it 
doesn't do anything. They are only basing on the gsettings key, while 
the switch shouldn't be sensitive.

I think we can fix all of this at the same time.

My proposal would be:
* Do not propose updating system extensions being part of a mode if his 
mode is the current one.
* If a there is an installed system extension and a local user one, but 
this extension is part of the current mode, only load the system 
extension code. This prevents people going to another session, being 
prompted to update the extension and doing so knowingly or not, and be 
back in an unsupported use case. The session mode will only run code 
that it knows about.
* This means reworking slightly the logic of the DBUS interface so that 
3rd party apps (Tweaks) or browser extension, shows up the correct 
status (extensions enabled/disabled, separated by updatable status or 
not, separated from error status, system or local user extensions). This 
would mean potentially changing and break the DBUS API, apdating -prefs 
and LG (easy same repo), Tweaks and browser extensions. Would that be 
acceptable? I can as well work on making it backward compatible and 
exposing a V2 api on the bus.

I'm happy to have a deeper look and work on this if the global approach 
has general conscensus. Happy as well to discuss any other 
thoughts/ideas fullfilling those requirements.

Thanks,
Didier