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 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>
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>
Prior to Geoclue v2.7, the location description did not seem to ever be
set. Now, the source used to determine the location is set as the
description. This can result in the location name in dateMenu to be set
as "WiFi", "GeoIP", etc., since we relay the description as the location
name to GWeather. Instead, pass an empty string so GWeather continues
to set the location name itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2729>
The translation functions we export from extension utils must
work with all extensions, not only the first that calls one
of the functions.
That means that we are back to examining a backtrace for every
function call unless an extension defined its own translation
functions with `import.meta.url`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2887>
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>
And a way to derive "sub"-adjustments from the main one.
The main and private StAdjustment properly represents
workspaces, and has all relevant properties (lower, upper,
and value) set by the workspace manager.
The main adjustment is not bound to any particular actor,
which means we cannot call the 'ease' method directly.
Consumers of this API should create adjustments using
Main.createWorkspacesAdjustment(), and this new adjustment
is bound to the actor that the consumer passed. Consumers
must not change any property of the derived adjustment other
than the 'value' property.
The 'value' property is synchronized between all adjustments
created, which guarantees that all elements that represent
workspaces can have a shared and up-to-date understanding of
where in the workspace layout we are.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
The Config module is shared between the main process, D-Bus
services and tests, which previously prevented it from being
ported to ESM.
The previous commit removed the last outstanding blocker, so
we can now port the last remaining module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Out of the members of the notification daemon(s), these are the most
necessary and flexible to override. The daemons are used as singletons
and notifications are rather temporary, while the sources are more
flexible and make the most sense to override (and revert).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2869>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
We have made good progress with transitioning to the new style,
to the point where we can complete it with a final push.
Start with changing the remaining places that still use double
quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
We sometimes obtained the current event through the general machinery
just so we could pass it along as a ClutterEvent instead of a specialized
subtype.
We now get that out of the box, so may avoid getting the current event
which is just a cast of the same current event we already have.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2950
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
Commit 17d9ec5788 made the input method call update() more eagerly,
but also at times that it does not have a cursor position yet. Make
it bail out correctly in that situation.
Fixes: 17d9ec5788 ("inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2876>
If context.focus_out() is called *after* context.set_capabilities(0),
The FocusOut D-Bus method is ignored because of no FOCUS capability.
If context.focus_out() is called *before* context.set_capabilities(0),
The 0 capability is set to the next focused context and the
FocusIn D-Bus method is ignored because of no FOCUS capability.
So context.set_capabilities(0) should not be called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6415
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2666>
The module is shared between the various D-Bus services and the
main gnome-shell process, so it was originally left out to allow
porting different bits at their own speed.
Now that everything has been ported to ESM, there is no reason
to not move that particular module as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2868>
