Re: GNOME Shell and system extensions being part of a mode

[Didier Roche <didrocks ubuntu com>]

Le 25/10/2017 à 18:28, Jason DeRose a écrit :
> On Wed, Oct 25, 2017, at 10:02 AM, Didier Roche wrote:
> > How come you are creating this breaking situation? Do you mind 
> > expanding on this?
>
> 1) Switch to Vanilla Gnome session. 2) Receive update notification for 
> system-provided extension and take action, updating it via e.g.o. 3) 
> Switch to Ubuntu session and have new unsupported version of extension 
> instead of ubuntu version.

No, as the proposal is (as already outlined on this thread):

For extensions being part of a mode, prefer system extensions. So, the 
3) will be:
Support extension in /usr/share/gnome-shell/extensions would be loaded 
instead of ~/.local/ one.

> On Wed, Oct 25, 2017, at 10:02 AM, Didier Roche wrote:
> > This is currently what we have done by changing the extension ID. 
> > However, as stated in my first blog post, there is the issue that 
> > potentially people will register the same name on extensions.gnome.org 
> > and own it. Or you can upload an empty extension which is just a hack…
> >
> > Also, I note that you will end up with "staled" extension as you 
> > meant, so I don't see how this is better than the first proposal? What 
> > does it fix that the proposal doesn't?
>
> If you were to upload the extension to e.g.o, why you have to upload an 
> empty extension and can't just submit the extension. Do they not provide 
> any value to users of other distros?

Not really, as told in my first thread:
- Ubuntu Dock is just Dash to dock with different default overrides, 
settings panel being disabled and another extension ID
- Ubuntu Appindicator is just a the KStatusNotifier extension with 
another ID.

Both were light-forked to control update mechanism.

My proposal would enable to remove Ubuntu Appindicator and replace with 
upstrema KStatusNotifier directly.

Once they are released to an ubuntu version, we don't want them to 
update with new features and potential regressions outside of the 
packaged version, which is QAed, in the ubuntu session. This is why they 
would be empty and never updated if we go on that path (which I don't 
really like).

> Basically what I was proposing was that when the extensions are 
> installed that they are namespaced somehow. So intead of:
>
> <path>/extensions/TopIcons phocean net
>
> There would be(some variation of):
> <path>/extensions/ubuntu:TopIcons phocean net
> <path>/extension/ego:TopIcons phocean net
> <path>/extension/github:TopIcons phocean net
>
> Tweak tool would show all three extensions with their metadata version 
> and namespace and the user (or session) could enable their desired 
> version, and e.g.o could show only extensions installed via itself. I 
> believe this would solve the underlying problem of competing delivery 
> systems rather than just solving this specific problem affecting default 
> ubuntu users alone.


This is clearly what is already in place, and have the underlined 
limitations I expose. It doesn't solve either the stalled extensions issues.

My proposal is to avoid us, for instance, having this light fork

This doesn't only affect default ubuntu users alone, but everyone 
providing a session with extensions as part of a mode, like GNOME Classic.

> It's not really clear to me if you are proposing completely blocking 
> users from updating even if they explicitly wish to (and if so, why?) or 
> you simply want to omit them from showing an update indicator within 
> e.g.o and not realizing this is an unsupported version. But, perhaps my 
> suggestion can be simplified by simply having e.g.o ignore the system 
> extensions? I believe that the chrome-gnome-shell notifier already does 
> ignore them.

I think your suggestion is even more restrive than my proposal. Maybe 
you don't really understand how GNOME Shell mode works and this is why 
there is this confusion.

If you ignore system extensions, then you won't be able to update dash 
to dock and others in any sessions, which is even more restrive for 
people wanting to do this. And no, the chrom-gnome-shell notifier 
doesn't ignore them.

Basically, what I outline is (this time, quoting myself, by adding ** to 
hilight important terms):
* Do not propose updating *system extensions* being part of a **mode** 
if his mode is the **current one**.

It means: in the ubuntu session for instance, KStatusNotifier (if reset 
by default, being part of the mode) won't be proposed for update. 
However, in the vanilla session, it will.

However, we are protected against unwanted updates by:
* 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**.

The consequence is that if people, as in your example, go to another 
session (like the vanilla one), update KStatusNotifier, then, when to go 
back to the Ubuntu session, the QAed code, part of the distribution 
(installed under /usr), would be loaded.


> On Wed, Oct 25, 2017, at 10:03 AM, Jan Niklas Hasse wrote:
>  > He can use the vanilla GNOME session then.
>
> How would this be communicated to the user? The vanilla gnome session 
> isn't even installed out-of-the-box with Ubuntu 17.10. The only thing 
> the user knows to try is disabling from Tweak tool and then the slider 
> does nothing. In the user's opinion, Gnome Tweak Tool just appears to be 
> broken.
>
> https://askubuntu.com/questions/966795/confused-on-the-new-tray-icon-and-dock-in-ubuntu-17-10-gnome
> https://askubuntu.com/questions/967175/disabling-the-gnome-dock-after-installing-dash-to-panel
> https://askubuntu.com/questions/968325/remove-second-panel-when-using-dash-to-panel-in-17-10
> https://ubuntuforums.org/showthread.php?t=2370670

Which is exactly, by providing a GNOME Shell API refactoring (which is 
the 3rd point of my proposal), will enable. Right now, as I told in my 
first, there is no easy way for GNOME Tweak tools and other extrension 
manager to know that you have an extension enabled by a mode which can't 
be disabled.

Hope this is more clear to you.
Didier