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>
Nowadays we can set up translations automatically, but only when
the domain is provided with the metadata.
This can be a problem, for example our extension templates use
the automatic translation handling that we recommend, but as a
result the code will throw an error unless `gettext-domain` is
added to the metadata.
Binding a text domain is cheap enough to not care about unnecessary
or duplicated calls, so add a final fallback to the UUID when no
domain was provided as parameter or in the metadata.
There is already a precedent with the `gnome-extensions pack` command
that falls back to the UUID when no explicit gettext domain was
included in the metadata.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2888>
Commit a72c95de changed the focus style for all system entries
to a more neutral color, as the stronger focus often clashes
with the wallpaper background on the lock screen.
However that is not a concern for entries that appear over the
neutral system background. Worse, the neutral focus indication
provides so little contrast with the background there that is
not much of an indication anymore.
Address this by restoring the old focus indication for the
generic system_entry mix-in, but override it specifically on
the lock screen to avoid the clash with the wallpaper background.
Fixes a72c95de
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6945
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6880
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2922>
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>
