Currently we periodically check for updated extensions, prepare
an update and perform it at the next login.
This is largely due to the fact that once an extension has been
loaded, its code is cached and reloading it would only make it
*appear* as updated, while in reality still running the old code.
Of course this only applies *once* we have loaded extensions.
Before that, it's possible to download and install updates, and
only then initialize extensions with their latest version.
The trade-off is that network requests, data download and extraction may
introduce a significant delay before extensions
are enabled. Most extensions modify the UI one way or another,
so that delay would likely be noticeable by the user.
Assuming that users are usually happy enough with the current
extension version, that trade-off doesn't seem worthwhile.
However there is an exception: After a major version update,
extensions are likely disabled as out-of-date, or at least
more likely to break (when the version check is disabled).
In that case delaying extension initialization to download
and install updates looks like the better trade-off, so do
that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2951>
When commit 4d963c432b introduced the global workspace adjustment,
it mostly copied the adjustment handling from the overview that it
set out to replace.
That includes cancelling ongoing transitions when the number of
workspaces changed. However that missed that transitions don't
happen on the main adjustment, but on the "child" adjustments
returned from `createWorkspacesAdjustment()`.
Address this by tracking all child adjustments, and cancel transitions
there as well when necessary. Use weak refs to not
interfere with garbage collection, in case an extension creates
its own child adjustment.
Fixes: 4d963c432b ("main: Introduce global workspaces adjustment")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7000
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2949>
Reportedly, non-alphanumeric key levels were able to stick by
happenstance, and let the user press multiple keys until explicitly
switching to a different mode. Reportedly, this broke, switching to
the default level after the first key press on the additional levels.
Since we have this information in the OSK key models (each level has
a "mode" field to either default/latched/locked), retrieve this
information for them for each level, and only reset to the default
level if on one of those latched levels, and the relevant key was not
locked through long-press.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The _commitAction() paths have early returns, which made resetting the
latched mode inconsistent depending on the paths taken to commit the
string. This made latched modes not return to normal on e.g. Shell
entries.
Make this happen outside the function, and after the only calling
point, so that the level is correctly reset on all situations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The window button is disabled when
- there are no windows
- we are in screen-recording mode
- the session mode doesn't allow windows
However the last condition is only taken into account when
opening the dialog, but not when switching from recording-
to screenshot mode.
Address this by updating the button's sensitivity in a separate
function, so the different conditions are considered consistently.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2944>
Some extensions want to modify the value of the MAX_THUMBNAIL_SCALE
constant. That is no longer possible, as exports are always read-only
from the outside.
Make this possible again by exposing the scale as a property on the
object itself, so extensions can override it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2939>
Since commit 6a23e8ee0f, we use the adapter state (that includes
transitional state) to indicate progress when a state change takes
a long time.
However on many systems, the delay happens on the rfkill side,
before a change request even reaches the adapter.
Address this by temporarily overriding the adapter-state with the
expected transitional state, until an actual adapter state change
occurs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5773
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2815>
We currently show the bluetooth toggle when Bluetooth can be
toggled via rfkill, or when there is a powered adapter.
While the latter condition is obvious - if there is a working
Bluetooth adapter, then Bluetooth is available - it does impose
a problem: We rely on rfkill for turning Bluetooth off, so if
rfkill is missing, the toggle is stuck.
We could handle that case and power off the adapter ourselves
when necessary, but then the toggle would just disappear when
turned off.
Instead, only show the toggle when rfkill is available, so we
can assume that turning Bluetooth on and off will work.
This is also consistent with Settings, which shows Bluetooth
as unavailable in this case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2815>
Meta.Rectangle was replaced by Mtk.Rectangle. Mutter defines a
typedef for compatibility, but it turns out that gjs fails to
pick it up.
Work around that by adding a small compatibility function
that prints a deprecation warning and returns the expected
Mtk.Rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2930>
We now hide ornaments by default. As some of the items in the
window menu can be checked, that means that they will now shift
horizontally, and no longer align with other menu items when
checked.
That's quite bad, and as the items in question don't form a
distinctive group/section, adding back the spacing only to
those two items would still look fairly awkward.
So revert back to the previous behavior for this particular menu,
and default to the NONE ornament.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2926>
The WorkspacesView may be scheduled to be destroyed during
relayout, and despite that go through the allocate() vfunc.
When that happens, the ::destroy handler is called early,
so the WorkspacesView clears this._workspaces in result.
When vfunc_allocate() is called, various paths rely on the
workspaces array being still populated, which is not the
case.
The existing check at vfunc_allocate() for the WorkspacesView
having no children is insufficient, since children are destroyed
as a result, not beforehand.
This results in the following warnings when going out of
overview:
JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:218:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:344:18
vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:223:33
removeWindow@resource:///org/gnome/shell/ui/workspace.js:856:29
addWindow/<.destroyId<@resource:///org/gnome/shell/ui/workspace.js:808:22
_updateWorkspacesViews@resource:///org/gnome/shell/ui/workspacesView.js:1023:38
prepareToEnterOverview@resource:///org/gnome/shell/ui/workspacesView.js:990:14
prepareToEnterOverview@resource:///org/gnome/shell/ui/overviewControls.js:740:33
gestureBegin@resource:///org/gnome/shell/ui/overviewControls.js:802:14
_gestureBegin@resource:///org/gnome/shell/ui/overview.js:409:33
_beginGesture@resource:///org/gnome/shell/ui/swipeTracker.js:601:14
_handleEvent@resource:///org/gnome/shell/ui/swipeTracker.js:173:26
@resource:///org/gnome/shell/ui/init.js:21:20
This always happens through the _updateWorkspacesViews() paths, so there
is a new WorkspacesView taking over and the one being destroyed should
silently go away.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6935
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2918>
Allow passing 'null' to setLevel and setLabel, so 'null' and 'undefined'
behave the same way.
Fixes a regression introduced by a42f7c23, which caused parts of old
notifications to persist into new notifications, or elements being
incorrectly made visible
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2917>
This gesture to switch the focused app was already a bit of a
compromise solution at the time it was added, its clunky way to
work (3fg long press, then taps with a 4th finger to switch
application) was pretty much picking up the remains of our
limited wiggle room (sticking to 3fg/4fg global gestures, since
2fg are application domain).
But then directional 3fg gestures took prevalence, and made it
easier to switch between applications. This small gesture remained
a bit of an easter egg, largely unused and unknown.
Fast forward to today, and it's being noticed in a bad way. The
changes to event handling and delivery to actions has made this
gesture take prevalence over the wee-bit-more-popular 3fg swipe
gestures, making those never become active and never trigger.
While a gesture framework is being investigated that might
help handle these situations (or, in a less undefined manner),
this doesn't seem like a case worth going out of our way to
hack around until that is in place. We can remove this, and make
all WM interactions go through the 3fg directional gestures.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2729
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2910>
This is a small helper function that is used by the DND handling
in the dash and its items.
It turns out that some extensions used to override it, which is
no longer possible: We don't export it, and if we did, it would
be read-only.
To make the function available again, expose it as static method
on the dash itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2903>
Quick Settings has become a popular extension point, but adding
items anywhere but the end has become harder since the indicator
setup was made async.
Address this with an addExternalIndicator() method that adds
indicator and quick settings items at reasonable positions.
At the same time, adjust the indicator setup to take eventually
added external items into account.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
We will need some more access to the menu's underlying grid to
provide extension API for adding additional quick items.
Expose a new getFirstItem() method that (surprise!) returns the
first item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
The QuickSettings menu currently only support appending items
at the end. Extensions can get around that limitation by accessing
the private grid property to move the item afterwards, but we don't
allow this in our own code.
Expose a new insertItemBefore() method that allows adding an item
before an existing one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
After removing the app name and icon, the next natural step that
was requested from the design team is to add workspaces indicators
to the top bar, where currently the Activities button is placed.
In addition to that, this is desired because there are known issues
with using "Activities" as a label for the overview. A more
comprehensive rationale for that can be found at [1].
Add an workspaces indicator replacing the Activities label in the
activities button.
The WorkspaceIndicators class controls how many workspaces dots
exists, their expansion, and the width multiplier. The WorkspaceDot
class takes the expansion and the multiplier, and applies it
internally so that we can get perfectly rounded dots at all
times without using CSS hacks.
The width multipliers are hardcoded, and defined by the design
team. We can revisit them later if necessary. Special care is
taken to not let these width multipliers result in fractional
widths.
When the number of workspaces changes, WorkspaceIndicators adds
new dot to the end, and animate them. When removing, scale the dot
out, then destroy it.
This does not work with workspace grids, but that's not supported
by GNOME Shell anyway, so no effort is made to cover this use case.
The button continues to have "Activities" as its accessible name,
but the label actor is removed.
Also adjust the padding of the activities pill, so it better wraps
the new indicators.
[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/227
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2902>
If a failure happened during initialization the shell does not provide
any debug information, and so only the error is shown without a stack
trace.
Since this information is provided, pass it as the error message.
Do not log this directly from JS so that we just use one termination
path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2899>
Create a derived workspaces adjustment using the new API, and
bind it to the 'progress' property. This is only done by the
MonitorGroup representing the primary monitor.
The progress value that WorkspaceAnimation operates on
represents the percentage within the workspaceIndices array
we are, so make sure to transform the percentage to the
correct workspace index.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
The getter of the MonitorGroup's 'progress' property sets
some values based on it, but doesn't notify the property
change.
Fix that by calling this.notify('progress') when the setter
is called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
Derive the workspaces adjustment used by OverviewControls (and
shared with WorkspacesView) from the main workspaces adjustment
using the new Main.createWorkspacesAdjustment() method.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
