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>
Looking glass is not just helpful for development, but also when
asking users to provide relevant information.
Having it in-tree makes it easy to reference, and ensures that
the documentation is still in a maintained place when plans to
retire the wiki go head.
The content is based on the [wiki-page] with updated code samples,
small sections on added features, and outdated references removed
(anyone remember project looking glass?).
[wiki-page]: https://wiki.gnome.org/Projects/GnomeShell/LookingGlass
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2932>
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>
Nowadays, Clutter knows what an implicit grab is, which gives
us already the feel that we are after with buttons (e.g. press
and drag on the button will not enter other actors meanwhile).
ClutterGrab was only added to provide that feel meanwhile, and
it's also slightly more intense (e.g. altering keyboard focus,
or triggering leave events on all parents of the button) which
may trigger side effects.
An example is the IBus candidates popup, where the pagination
buttons may indirectly trigger dismissing of the entire popup
when interacted, by stealing the keyboard focus to the
client/actor doing IM.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2497
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2244
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2924>
