Le 16/04/2018 à 15:10, Paul Court a écrit :
Apologies in advance if this gets mixed up. I'm trying to reply to a
thread which was in progress before I joined the mailing list.
I'm struggling to fully follow the in and out on the web version of
the thread
(https://mail.gnome.org/archives/gnome
Apologies in advance if this gets mixed up. I'm trying to reply to a thread
which was in progress before I joined the mailing list.
I'm struggling to fully follow the in and out on the web version of the
thread (
https://mail.gnome.org/archives/gnome-shell-list/2017-October/msg00034.html),
but if
Hey everyone,
As there were no additional feedback, I just went ahead and worked
yesterday and this morning on this.
The result and attached set of patches are attached on
https://bugzilla.gnome.org/show_bug.cgi?id=789852.
I tried to summarize the various point, minimizing API change and
imp
2017-10-26 10:45 GMT+04:00 Didier Roche :
> ...
> And no, the chrom-gnome-shell notifier doesn't ignore them.
>
I have plans to make this optional so users can choose - whether they want
to check updates of system extensions or not.
But obviously this will not resolve your issue.
P.S.: Sorry fo
Thank you for the clarification on your proposal. The fundamental
disagreement I have is with the idea that "you can consider extensions
enabled as part of a mode as being really part of the Shell". I believe
this to be confusing and frustrating to users already familiar with the
extension ecosyste
I'm really consciencous that the content is a little bit dense, but I
wanted to lay out the problems and thinking I had gone through when
getting into it. Talking with csoriano, I think I came up with a nice
summary for this proposal:
Extensions enabled by a mode are part of the shell itself.
2017-10-25 14:15 GMT+04:00 Didier Roche :
> I want to propose some thoughts and potential rework around system
> extensions which are part of a mode towards update & QA process.
> ...
>
> My proposal would be:
> * Do not propose updating system extensions being part of a mode if his
> mode is the
2017-10-26 10:45 GMT+04:00 Didier Roche :
> ...
>
> 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.
>
>
> Hope t
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 a
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
On Wed, 25 Oct 2017, at 15:51, Jason DeRose wrote:
> What one user calls "supported" another calls "stale". Just because a session
> enables an extension doesn't necessarily mean the user wants the old version
> of the extension.
He can use the vanilla GNOME session then.
> (I don't like that
Le 25/10/2017 à 15:51, Jason DeRose a écrit :
On Wed, Oct 25, 2017, at 09:12 AM, Didier Roche wrote:
The issue of letting users upgrading is the proposal of
auto-updating. Nothing will tell that a new release of distribution X
will have a newer GNOME Shell, and so, version compatibility check
On Wed, Oct 25, 2017, at 09:12 AM, Didier Roche wrote:
>
> The issue of letting users upgrading is the proposal of auto-updating.
> Nothing will tell that a new release of distribution X will have a
> newer GNOME Shell, and so, version compatibility check (which is
> currently disabled in most pla
Le 25/10/2017 à 13:22, Jason DeRose a écrit :
The problem you describe is a real issue. The flip problem is also an
issue, where the user intends to install a newer version. This is an
issue in distros where many extensions are shipping out of the box,
and the package manager competes with e.g.
On Wed, 25 Oct 2017 at 12:15:37 +0200, Didier Roche wrote:
> 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
I think GNOME Classic mostly dodges this by its extensions being
relatively tightly cou
On Wed, Oct 25, 2017, at 06:15 AM, Didier Roche wrote:
> 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
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 I
17 matches
Mail list logo
