We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.
But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).
And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
It's unfortunate that we cannot fully embrace template strings, but
we aren't limited to "legacy" formatting either; replace the last
remaining places where we still use string concatenation to reduce
the difference between regular and legacy style a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
This commit adds support for Home and End keys to move
to the first and last workspace respectively.
Previously only Page_Up and Page_Down were recognized
to move one workspace at a time in overview mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2201>
The event passed to formatEventTime() is reused at a later point.
Therefore, we are not allowed to manipulate the event directly.
This fixes an issue where the user clicks on a multi-day all-day event
the second time before the event gets garbage collected and the event
then is one day shorter.
Fixes 528ee01fef
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2184>
WorkspacesDisplay connects to key-press-event on the stage to switch
workspaces when page up or down is pressed and nothing else intercepts
these keys. This means that it is still possible to switch workspaces
while they are hidden behind the search.
So only allow these keybinding while the WorkspacesDisplay is reactive
which gets updated by ControlsManager depending on whether there is an
active search or not. Also set it as initially reactive, because
otherwise the keybindings would only work after performing an initial
search.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2204>
We're calling get_interval on tzA right now for both the tzA and tzB,
this causes a critical error during shell startup:
g_time_zone_get_offset: assertion 'interval_valid (tz, (guint)interval)' failed
Fix this and use tzB to get the offset for timezone b.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2195>
While _sync() does already handle the case where there's no adapter just
fine (hiding the item and the indicator), let's make the handling a bit
more obvious and add an explicit check for !this._adapter where we bail
out and hide the UI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2188>
There's two ways bluetooth can be powered off/on for us: One way is to
go via airplane mode (which uses rfkill), and the second way is to tell
BlueZ to turn off the device. Now rfkill always has the final say on
whether bluetooth is off, BlueZ OTOH has the final say on whether
bluetooth is on.
This means when we want to know whether bluetooth is turned on, we only
have to ask BlueZ, so simply read this._client.default_adapter_powered
for that.
For turning bluetooth on or off we use rfkill, but when turning it on,
make sure it's turned on in Bluez, too.
FTR, this is exactly the same way the Bluetooth panel in Settings
handles this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2188>
We currently use get_color(), which assumes the color exists in the
stylesheet (and prints a warning if it doesn't).
Switch to lookup_color() and skip filling the background if no
such colors exits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2172>
The original popup included arrows that indicated the direction of
the switch. We stopped doing that a long time ago, and ever since
the popup has only indicated active vs. non-active workspaces.
Simplify both the API and style to reflect that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2127>
The indicator shows the recording duration and lets the user stop it on
click. It is more discoverable than the stop entry in the aggregate
menu.
The class extends ButtonBox directly rather than Button because Button
does nothing that it uses, and actually causes issues with its dummy
menu (its vfunc_hide() throws an "open-state-changed: Error: incorrect
pop").
The menu-set signal declaration is required by the panel.
The screencast is stopped upon button press in vfunc_event(), which
matches PanelMenu.Button's input handling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2163>
In a subsequent commit we will add a function to open the screenshot UI
in the screencast mode. This argument will allow us to do that without
resorting to accessing private fields from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
This way we don't need to uncheck the other button manually, and it also
allows switching the mode by setting the other button's checked to
false, and not just by setting the target mode's button to true. An
example clean-up can be seen in the "V" key handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
These two are moving into gnome-shell to unify screenshot handling and
allow for same-frame capturing.
While we're at it, move the keybindings .xml file from g-c-c here
because it belongs to gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
We will re-use the same modes for more bindings in subsequent commits.
Also, while we're at it, invert the modes, to emphasize where the
screenshot UI cannot be used, rather than where it can be used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
It will be used for the window right-click menu and for handling keys
that are moving here from g-s-d.
Lockdown settings are also moving into the split _storeScreenshot() as
that is the only place where they are used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2105>
- drop card style from calendar
- remove focus ability from non-interactive calendar elements
- flesh out the styles for the calendar grid
- fix margin and padding issue with login screen calendar
- update no-notifications icon
- add padding to media player buttons
- catch a couple other minor style papercuts
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2161>
This reverts commit fdac0602db.
The commit was fixing a crash, which cannot longer be reproduced, but also
introduced a noticeable white flash when switching wallpapers. This will
become even more noticeable when we try to uniformly transition the whole
screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2070>
If the finish function isn't specified, promisify will now try
to use the async name without '_async'/'_begin' suffix (if any)
and '_finish' appended.
Everything except IBus uses a variation of that pattern, so there's
quite a bit of boilerplate we get to remove…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2174>
As users can have different primary mouse buttons (left vs right) it
might happen, that a user with a different
preference wants to switch. Currently they need
to use the mouse button, that the current
user prefers.
This change enables users to use either the left or right button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1972>
Currently when switching from a popup menu to another in the same
manager, we first show the new menu, then hide the old menu and
remove its grab, then create a new grab for the just shown menu.
This briefly ungrabbed moment will still trigger keyboard focus
changes, that might have other visible effects. In order to fix
this, change the grabbing order so first the new grab is created
then the old one is dismissed. This ensures focus moves from the
old menu to the new menu without gaps in between.
Since a grab is tied to an active menu, but close/grab are now
slightly decoupled, also ensure closing a menu only tears down its
own grab. This is necessary for correct accounting while doing the
grab shuffling.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5039
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2166>
- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
CSS and JS adapted from the Overview window close buttons, but with some
style tweaks requested by the designers.
Since the screenshot UI is long-lived (it's created once at startup,
rather than every time it's opened), we need to refresh the close button
position, as it can change at runtime. Subscribing to preference changes
seems to be skipped for bindings generation in Mutter, but simply
refreshing upon opening the UI should do the job.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4997
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2147>
This was here exclusively to silence out events from other pointing
devices in the stage. Since ClutterGrab being used now is global to
all devices and events are coerced to an invisible actor, there is
no need to explicitly do this.
Also, this event handler was set on the stage, while the grab happened
on a child, so it was fairly uneffective already.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2146>
Since the grab no longer lets events bubble up to the stage unstopped,
we should be forwarding the key events that bubbled up to the dialog
to maybe cycle focus.
Fixes broken keyboard navigation in several context menus around the
shell, other than the panel ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
Since the grab no longer lets events bubble up to the stage unstopped,
we should be forwarding the key events that bubbled up to the dialog
to maybe cycle focus.
Fixes focus cycling on keyboard navigation inside dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
Connecting to stage events won't work from a modal dialog, since the
grab will take events from the portions of the actor hierarchy above
the grabbing actor.
Connect to events from the dialog itself, so that the end session
dialog can again show the "boot options" easter egg.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
Commit d92b71d2b2 went overeager in the removal of the additional
actors that were allowed to handle events (since the new grab
infrastructure makes them unable to see events in the first place),
and removed an early return in the captured event handler meant to
let events go through in those cases.
Since the grabbing actor was also part of this group, this was also
the code path where child actors of the grabbing actor could handle
events. Removing these made the captured event handler eat most
events meant for children. Add this check back, specifically for the
grabbing actor.
While at it, explicitly check (and propagate) crossing events,
since these are now enforced to be propagated (and warned about) in
Mutter.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4991
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
With the new boolean setting, the "High Contrast" toggle can now
simply toggle the setting instead of the current gtk/icon-theme
shenanigans.
This isn't only much simpler, but will also make switching between
high-contrast and a non-default theme reliable at last.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2069>
Workspace transition stopped midway when the Meta key
was released while the two-finger scroll gesture was
in progress. This commit ignores the Meta key once
the gesture has been confirmed and is in motion.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2135>
This is specifically for stopping the screenshot UI screencasts for now.
It's possible to stop arbitrary screen recording handles, however due to
an issue with pipewiresrc, this method cannot currently work for cleanly
stopping Shell's own screen recordings. Hence the best we can do is to
handle just the screenshot UI screencasts to let them stop cleanly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
The screen recording menu entry will use this to check if a screencast
is currently active and to stop the screencast.
Use a GObject property so we can bind to notify; specifically we'll bind
the visibility of a screencast area indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
Currently does nothing. When we're in screencast mode, we hide the
screenshot preview because screencast doesn't start until the capture
button is pressed.
The window selection is currently left as is, but it should probably be
changed to something closer to a real overview, showing windows in
real-time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
And set the dialog actor reactive. Specifically, we do not know whether
the parent actor is reactive or not, and we should not be changing that
from here, so do not use that actor to handle key events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
All callers have been updated to keep this handle to identify their
own grab.
Also, optionally use the windowing state to determine whether
the grab is suitable for the specific uses. This removes the need
to trying to grab twice in the places where we settle for a keyboard
grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
With the presence of Clutter.grab(), this behaves differently enough
that needs some redoing. The larger difference is what actors are
eligible for handling events.
In the older code, a PopupMenuManager would ask the grabHelper to
capture events from all the stage, and selectively silence events
on any actor that is not the currently shown popup menu or the
"source" actor for any other popup in the group (i.e. those that
would pop up another menu).
But we don't want to just silence events, we want to emit the
correct set of crossing events when a popup menu is shown or closed,
this requires a backing ClutterGrab() on the currently shown menu.
Since the presence of a grab also affects the ability to have actors
outside the grab area to handle events, the PopupMenuManager now
must detect hovering and focus changes to other menu sources by
handling events on the grabbed popup itself.
Redo the grabbing over Main.pushModal/popModal (i.e. ClutterGrab,
plus keyboard focus restoration) and a captured event handler on
the currently shown menu, to make PopupMenuManager behave as it
is expected with this new kind of grabs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
This is subject to further possible simplifications. Use Clutter.grab
to redirect input and focus, a fundamental difference here is that
we do redirect input to the topmost owner of the grabhelper stack,
instead of the stage. This is better behaved with the presence of
other grabs, at the cost of some behavioral changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
While the menu is popped up, we artificially keep the icon highlighted
by ensuring it's hovered, and muting events on the app icon until the
menu is popped down.
This is somewhat convoluted and won't work with Clutter.grab(), where
it will be the menu itself that is the owner of input events while
shown, so cut some corners and explicitly tell the app icon to be
highlighted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
We want to mute things like pointers hovering the BoxPointer while
it does open. However keyboard events should still be handled
promptly.
Since Clutter.grab() will involve different actors being grabbed
and focused, this will have some more presence, e.g. when navigating
panel menus. We want to be able to navigate outside a menu while it
is still being shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
Some dialogs like the runDialog expect this actor to receive
key events while it is not reactive. Whatever that black magic was
it will no longer work.
Make the actor reactive, so it can simply handle key events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
If a menu item in a submenu is part of a section, it should have
rounded bottom corners if both the item and the section are the
last child of its respective parent.
To express that, add a new .popup-menu-section class and use that
to undo/redo the rounding for items inside a section.
It would be possible to do without a new class with a selector like
> StBoxLayout > .popup-menu-item:last-child:hover,
:last-child > .popup-menu-item:last-child:hover
but that's hardly better with its heavy reliance on implementation
details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4940
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2126>
The cursor texture, scale and position is captured separately and
overlaid on top of the preview, and on top of the final screenshot
image. This allows toggling it on and off post-factum.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Allow switching the screenshot mode by pressing the "s", "c", or "w" key. Also
implement arrow-key navigation between monitors in the screen screenshot mode
and between windows in the window screenshot mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
UIWindowSelectorLayout is a stripped-down subclass of WorkspaceLayout
(we don't have to deal with windows disappearing or appearing or
changing size). UIWindowSelectorWindow is a heavily stripped-down
version of WindowPreview. UIWindowSelector is analogous to the Workspace
class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Right now, _setIconSize() calculates the icon size everytime the
preferred height of AppSwitcher is calculated, which happens quite
often.
Reduce the perfomance impact by only calculating the icon size once.
This has the added benefit of preventing unexpected changes to the icon
sizes while the switcher is open.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2098>
Just like in the parent _onItemMotion() function, we should check for
reentrancy in our override.
Because the hover timeout will prevent a new selection from happening
for some time, in addition to checking for this._highlighted reentrancy,
we also need to track the item that's being hovered during the timeout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2098>
When passing an invalid or unknown app ID to FocusApp(), we currently
open the app picker and silently fail to select the desired app.
Instead of half-working like that, make it clear that the argument
was invalid by returning an appropriate error. (It's easy to get the
ID wrong, as unlike appstream/flatpak IDs, we include the ".desktop"
suffix).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/337>
Hiding the `WorkspacesDisplay` triggers a reallocation of the
`ControlsManagerLayout` which can fail with the following error:
```
JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:229:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:355:18
vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:200:33
vfunc_hide@resource:///org/gnome/shell/ui/workspacesView.js:1070:38
vfunc_unmap@resource:///org/gnome/shell/ui/overviewControls.js:672:33
hideOverview@resource:///org/gnome/shell/ui/layout.js:312:28
_hideDone@resource:///org/gnome/shell/ui/overview.js:617:32
onComplete@resource:///org/gnome/shell/ui/overview.js:390:37
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:134:13
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:298:60
```
This can be reproduced by closing the overview with the three-finger
gesture.
Thus propagate the unmap before hiding the `WorkspacesDisplay`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2088>
The unfullscreen gesture was defaulting to enabled until the first
window focus change. With it now being run in the capture phase, the
gesture was preventing clicks in the top panel except on the activities
button before the first window was opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2087>
Currently only banners in the SHOWN state are hidden when the underlying
notification is destroyed, but if they are in the SHOWING state, they
remain visible. Because the 'notification' member has already been set
to null when the notification got destroyed, closing the banner by
clicking on the close button, will not do anything and clicking on the
notification itself will result in an error message. For notifications
without a timeout, i.e. critical ones, this will result in an
uncloseable notification.
This can happen if the program creating a critical notification
immediately closes it again, as might happen with power notifications
from gnome-settings-daemon in some situations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4855
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2079>
Besides dropping its GTK dependency (which doesn't affect us),
GWeather 4.0 replaces its own timezone type with GTimeZone.
It's easy enough to adjust to that, so port over to the new
version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2083>
The WorkspaceGroup class in defined as CONST, which means that,
strictly speaking, is inaccessible from outside the file
workspaceAnimation.js. But Desktop Icons NG needs access to it.
Although the current Javascript engine "tolerates" this access,
a warning message is shown in the log advertising that it's
incorrect, and that although it is still allowed, the code
should be fixed.
This patch changes the definition from CONST to VAR to allow
accessing it from extensions.
jk
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2068>
Firstly don't use EASE_IN for any minimize/unminimize animations because
those start slow and end fast. The effect of that was minimize/unminimize
appearing to be unresponsive to user clicks for a little while before
accelerating away. All such animations should be EASE_OUT for an immediate
response followed by deceleration at the end.
Secondly we replace the shallow 200ms QUADratic curves with a steeper
400ms EXPOnetial curve. Because it's steeper and twice as long the fast part
feels the same as 200ms QUAD, but there's an extra 200ms after that in which
to slow down smoothly giving a more fluid appearance. No sudden stops.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=786789
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
If you slow down the unminimize animation you will notice it overshoots and
then snaps back, but only for decorated windows. Undecorated windows would
unminimize to their correct position. So we remove decorations from the
equation and now all window types unminimize to their correct position.
This wasn't noticeable because the unminimize animation velocity is usually
so high at the end (EASE_IN_EXPO) that there are no frames rendered near the
end of the curve to show it had overshot.
This appears to be consistent with the Mutter source - associating the
actor geometry with `buffer_rect` and not `frame_rect`. See
`meta_window_actor_sync_actor_geometry` for example.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=786789#c1
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Given the correct end date this code would be able to determine this
correctly itself and doesn't need to rely on that property. And events
without correct end dates are currently not shown anyway. This prepares
for removing the allDay property entirely.
This also fixes events going from 13:00 the current day to 01:00 not
showing "...". It also fixes multi-day events wrongly detected as
all-day events by the calendar-server showing up as "All day", despite
only covering 1 hour of the day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Events with a date time (not just a date) where the end time is missing
or matching the start time were considered to not overlap the selected
interval if they were happening on the start time of the interval. This
was causing such zero-length events to be omitted from the calendar if
they were starting at 0:00.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Using a starting time other than 0:00 will prevent events before the
chosen starting time from showing up for that range. This was causing
events before 12:00 to be missing in the shell calendar on the first day
of a range.
Fix this by always starting at 0:00 and then incrementing by days rather
than a time value that depending on DST or leap seconds may or may not
correspond to a day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
The ical events, we are comparing these intervals to use the first point
in time after the end of the event as their end time, while the code in
gnome-shell was using the last point in time within the range. This was
causing multi-day events ranging from 0:00 to 0:00 to have a trailing
"..." shown on the last day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
MetaContext:unsafe-mode was added as a debugging tool to temporarily
remove restrictions on privileged APIs. But as it turns out, there
are now extensions that toggle the property permanently. Right now
none of them are malicious (as far as I can see), but it's still a
bad idea and should be discouraged.
Do this with a notification that warns the user when unsafe mode is
enabled non-interactively (i.e. via looking glass), and hopefully
also clarifies what the weird lock icon in the top bar is about.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2050>
libgnome-bluetooth will start to offer a 2.0 library version
depending on GTK4. Given that GNOME Shell already depends on
GTK3, it cannot use this next version of gnome-bluetooth. And
since GJS will automatically try and use the latest version
available of any library, Shell must specify it wants 1.0
explicitly.
Add a required GnomeBluetooth version number when importing it
for the status indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2015>
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
Now that we allow extensions at the lock screens, extensions
are allowed for every session mode gnome-shell would typically
change to at runtime.
This means there's little advantage to having an allowExtensions
property in the session mode definition.
This commit simplifies the code a bit by dropping the property.
Third party session modes can still lock down extensions through
gsettings if they need to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
Now extensions can specify which session modes they work in,
but specifying the login screen or unlock screen session modes in
an extensions metadata still won't work, because those session
modes disallow extensions.
This commit fixes that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
At the moment it's not realy possible to extend the login screen to do
things it doesn't have built-in support for. This means in order
to support niche use cases, those cases have to change the main
code base. For instance, oVirt and Vmware deployments want to be able
to automaticaly log in guest VMs when a user pre-authenticates through a
console on a management host. To support those use cases, we added
code to the login screen directly, even though most machines will never
be associated with oVirt or Vmware management hosts.
We also get requests from e.g. government users that need certain features
at the login screen that wouldn't get used much outside of government
deployments. For instance, we've gotten requests that a machine contains
prominently displays that it has "Top Secret" information.
All of these use cases seem like they would better handled via
extensions that could be installed in the specific deployments. The
problem is extensions only run in the user session, and get
disabled at the login screen automatically.
This commit changes that. Now extensions can specify in their metadata
via a new sessionModes property, which modes that want to run in. For
backward compatibility, if an extension doesn't specify which session
modes it works in, its assumed the extension only works in the user
session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
At the moment a session mode either allows extensions or it doesn't.
If it allows extensions, then the entire available list of
configured extensions get enabled as soon as the session mode is
entered.
Since enabling or disabling extensions is an all or nothing situation,
the code tracks whether extensions are already enabled when entering
the session mode, and if so, avoids iterating through the extension list
needlessly. It does this using a boolean named _enabled.
In the future, the extensions themselves will be given some say on
whether or not they should be enabled in a given session mode. This
means, the configured extension list may contain extensions that
shouldn't be enabled for a given session mode, and the _enabled boolean
will no longer be appropriated.
This commit drops the _enabled boolean optimization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
If a user hits escape twice really fast when coming back to
their machine to unlock it, they made end up getting presented
with a non-functional unlock screen that doesn't show their
user icon and doesn't ask for a password.
This is because showPrompt assumes that if an auth prompt already
exists, it's ready to go. That may not be true, if it's in the
process of getting torn down at the time because it's in the middle
of a cancel animation.
This commit solves the problem by ensuring the auth prompt is always
in a fresh reset state before showing it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
If the the unlock dialog gets finished before an auth dialog is
created, the code currently creates one just to tell it to finish.
This commit changes the code to skip creating the auth dialog in
that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
Commit dd2cd6286c restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1990>
Previously we used `get_image()`, which returned `cairo_surface`,
in order to create a `ClutterContent` with a screenshot of the
`MetaWindowActor`. This added a roundtrip from GPU to CPU memory.
Instead, use the new `paint_to_content()` API which lets us use a
`CoglTexture` directly as source of our `ClutterContent`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1879>
The Eval() method is unarguably the most sensitive D-Bus method
we expose, since it allows running arbitrary code in the compositor.
It is currently tied to the `development-tools` settings that is
enabled by default. As users have become accustomed to the built-in
commands that are enabled by the same setting (restart, lg, ...),
that default cannot easily be changed.
In order to restrict the method without affecting the rather harmless
commands, guard it by the new MetaContext:unsafe-mode property instead
of the setting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3943
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970>
Since touchpad smooth scroll events with source finger are handled by
the swipeTracker, the workspace scroll handler can focus on discrete
events.
Thanks to Mutter emulating discrete scroll events, see
meta_seat_impl_notify_scroll_continuous_in_impl in meta-seat-impl.c,
it is safe to ignore smooth scroll in the workspace scroll handler
and handle exclusively discrete events.
In addition, once high-resolution scroll events land in Mutter [1], a
mouse will be able generate non emulated smooth scroll events that
should be ignored in favour of the discrete scroll events.
Otherwise, a single mouse wheel click will scroll through multiple
workspaces at once.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1959>
The keyboard is placed outside of the screen when shown and then slides
in via a transition that changes the translate-y property. This
translation does not affect the allocation of the Keyboard actor and as
such does not trigger any of the signals LayoutManager is connected to
to update the input region. This means the input region remains at the
original position of the actor outside of the screen and as a result on
X11 clicks will go through to the underlying window.
There was a workaround for this by queuing a relayout at the end of the
transition, but this stopped working due to optimizations avoiding
unnecessary allocation changes.
This updates that workaround to toggle the visibility of the actor
instead, which is the other signal that LayoutManager reacts to. Once
ClutterActor provides better ways to react to transforms this can
hopefully be removed entirely.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1955>
Sometimes when an icon is dragged and dropped in Dash, one Favourite app icon
can appear to the right of Dash separator. This can happen when available system
resources are low and the PlaceHolder destroy animation is delayed and the
corresponding container child is still present. With this commit the separator
position is calculated correctly, even when the animation is pending.
Fixes#3966, #3799
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1804>
eee2ccac fixed window opacity being changed outside of transitions but
resulted in the final step of the transition, that would set the window
to fully opaque, being missed.
This change now moves the opacity change entirely out of allocation and
instead follows the adjustment changes directly, which still fixes the
original bug and ensures the opacity is also applied for the last step
in the transition.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4561
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1957>
GJS added a console module that extensions may start using. To ensure that
extensions using console.log() and similar functions don't show up as
'Gjs-Console' in users' system logs, we should call setConsoleLogdomain()
with 'GNOME Shell'.
This GJS API addition is only accessible using ECMAScript Modules (ESM),
this commit moves shell startup to a small init.js module and adapts
CI jobs to either handle or ignore it.
We can drop the .jscheckignore file when future versions of SpiderMonkey
allow for compile checks without validating module specifiers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1958>
!1940 added support for soup 3, including a fallback to soup 2.4
where the newer version isn't available.
Unfortunately it missed that libgweather has a hidden soup dependency,
and now gnome-shell fails to start if a weather location has been set
up and soup 3 is available.
We don't have a good way to detect that case, so hide the soup 3 support
behind a build option. Distributors are expected to switch it at the
same time as libgweather.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1966>
Unlike for the old Soup.SessionSync/SessionAsync classes,
Soup.Session:ssl-use-system-ca-file already defaults to true.
In Soup3, the behavior was made unconditional and the property
removed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Quoting the documentation:
In libsoup 2.44 and later, you can set the session's “proxy-resolver”
property to the resolver returned by g_proxy_resolver_get_default() to
get the same effect. Note that for "plain" SoupSessions (ie, not
SoupSessionAsync or SoupSessionSync), this is done for you automatically.
libsoup 2.44 was released in 2013, so we can safely assume that Soup is
new enough to handle this for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
The code that handles extracting extension archives currently uses
an awkward double-callback system. We can do significantly better
by using an async function and exceptions.
Partially based on code from Marco Trevisan.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Move all remaining bits to the new coding style before making
further changes.
The let → const changes are selectively done to the bits that'll
still be around at the end of the patch series.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Which better communicates what we are checking for, and is a little more
elegant than repeatedly writing:
```
Main.overview.animationInProgress && Main.overview.visibleTarget == false
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1440>
We hide our own "New Window" item if the app itself includes a
"new-window" action. That means that the separator between the
built-in item and desktop actions introduces a small inconsistency
depending on whether a "New Window" item is provided by the desktop
action or ourselves. There's no good reason for that from a user's
perspective, so remove the separator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The context menu in the overview includes actions for managing
favorites. Add those to the AppMenu class, but make it another
option as the actions would be slightly weird in the top bar menu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The top bar menu always corresponds to a running app, so it made
sense to include the 'Quit' item unconditionally. That won't be
the case for the overview context menus, so handle app state changes
and show/hide the item as necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
Since commit fd0da9606f, we only show the "Open Windows" section
if there are at least two windows. That's another subtle difference
with the overview context menus, but while limiting the section to
a minimum of two windows makes sense where the menu always represents
a running app, it is useful to show the section even for single windows
in the dash/app grid.
Account for both uses cases by adding a corresponding option to the
constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There's a subtle difference between the top bar menu and the app
icon context menus in the overview regarding the "Open Window"
section.
The former includes skip-taskbar windows, the latter doesn't. It
clearly doesn't make sense for the context menu to include windows
that aren't shown in the overview, but skip-taskbar windows are
likely also less useful in the top bar menu.
Just settle on the behavior of the context menus and move on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
This is the expected behavior when activating a window or app. Until
now we could rely on the menu being hidden in the overview, but as
that is about to change, make sure the menu behaves as expected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
App windows are ordered by recency, so a focus change (correctly)
triggers the ::window-changed signal. If we rebuild the section
immediately in response, the activating item will be destroyed
before the menu's ::activate handler, with the result that the
menu remains open.
Defer the section update in that case to allow the menu to process
the ::activate signal first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
For now the menu is only used in the top bar, where we can assume
that it exists "forever". This won't be the case when we start
reusing it elsewhere, so make sure we clean up after ourselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There was a potential issue when suspend was inhibited and immediately
uninhibited again before the creation of the inhibitor has finished.
Then the new inhibitor would be kept active.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
ScreenShield::_syncInhibitor() was closing (and recreating) the
inhibitor everytime it was called, even if no change was needed.
This gets called in various places, including on property changes in
the login1 dbus object. These happen by the time logind already started
suspending at which point new inhibitors can no longer be created. It is
only waiting for existing inhibitors to be closed, so closing the
inhibitor without a new inhibitor will cause the suspending to proceed
immediately if no other inhibitors are present. This can also happen
before the lock screen is shown, which will then complete after resume.
Fix this by keeping track of the expected inhibition state and only
create or close inhibitors if there was a change to that.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3736
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.
This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137https://bugs.launchpad.net/bugs/1936643
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
The PointerWatcher passes the current pointer position to every watch,
so we don't have to query the pointer again scrollToMousePos() is used
as watch callback.
While that should be the only use, be conservative and still query the
pointer when called without arguments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1932>
Right now the Show Password menu is shown unconditionally for password
entries, ignoring the org.gnome.desktop.lockdown disable-show-password
key.
StShellEntry now honors that key for its peek icon, and there's little
reason for the peek icon and the menu to ever be out of sync.
This commit forces the menu and the icon to always be in sync, and
so makes the menu lock down work automatically, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
The behavior when switching workspaces now with the touchpad gesture is
very very weird, it almost always swipes to the last workspace instead
of the next one.
So revert this change again and only swipe a single page per gesture. We
can enable long swipes again when we've figured out a proper way to
detect what the user wants (which is going to be quite challenging), see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4355.
This reverts commit dfae3281b9.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1933>
ClutterVirtualInputDevice::notify_keyval() expects time to be in
microseconds but Clutter::get_current_event_time() returns the time in
milliseconds. On Wayland the generated event triggers all the warnings
in MetaDisplay::sanity_check_timestamps() due to the event time
seemingly being in the past.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1926>
Dragging a window preview in the overview is supposed to change the
opacity of the dragged actor. This however fails for minimized windows,
because Workspace::allocate() also changes the opacity of those. The
allocation gets triggered by removing the window actor from the
workspace when starting the drag. Avoid this by only changing the
opacity during the overview transitions.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4292
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1847>
At the moment user switching functionality is controlled by two
settings:
org.gnome.desktop.lockdown disable-user-switching
for the panel when the session is unlocked, and
org.gnome.desktop.screensaver user-switch-enabled
for the unlock dialog when the session is locked.
Having the lockdown setting not apply when the screen is
locked is counterintuitive.
This commit makes the unlock dialog honor both settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1833>
Since this is a bin and not a button, and it doesn't have any click/keyboard
handling on its own (as in that case it needs a parent button wired like in
the messages list controls), it is confusing that it has can_focus set to
True. To avoid any confusion, this commit removes it without breaking anything
since it had no real use.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1920>
This one was moved to Meta.Context as well.
I don't know why the `debugexit` command quit with an error code
(it dates back all the way to commit 98bd590a5d). Terminating on
request by the user doesn't sound like an error, so don't replicate
that particular behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1917>
Before this, creating a separate instance of `Location.Indicator` failed
because it tries to create export the same DBus path.
This is useful for extensions adding panels on multiple monitors. But
it also seems like a cleaner design to separate the indicator widget
from the logically separate role as a Geoclue agent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1919>
We build controls layout using the whole monitor vertical space as
available, however extensions or external apps in X11 may reduce the
workarea size horizontally and the shell should always take care of it.
Given that we're already assuming that the allocation is monitor-based
and that we're adjusting it to the workarea, we can just make it more
explicit by using a workarea box that is used as the allocation area.
As per this, we also apply the same logic of applied to the vertical
dimension to the horizontal one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
To compute the available height for the layout we're currently using the
panel position, while this works for the current and default setup, the
shell may be configured to use a different workarea, so we should rely on
it to compute the available space, instead of a specific widget.
So get the current monitor index for the current view and use its coordinates
instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
The background group is currently allocated taking care of the workarea
x, y offset but not of its width/height and this may lead to building a
wrongly sized workspace view when the workarea size is not matching the
monitor size (like when there are struts set).
So, take care of the difference between the workarea and monitor
absolute end coordinates to allocate the background scaled content box.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
We currently disable all network items on both the lock- and login
screen. While it makes sense to be very restrictive on the lock screen,
there are some (fringe) use cases for being more permissive on the
login screen (like remote home directories only accessible via VPN).
There's precedence with the power-off/restart actions to be less
restrictive on the login screen, and since we started respecting
the `network-control` polkit action, it's possible to restore the
old behavior if desired.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
NetworkManager installs a `network-control` polkit action that can
be used to disallow network configuration, except that we happily
ignore it. Add it to the conditions that turn a network section
insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
Setting up a connection for an Enterprise WPA(2) encrypted wireless
network requires Settings. That's not available when windows are
disabled via the session mode, so filter out affected entries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
The item launches the corresponding Settings panel when activated, which
doesn't work when windows are disabled by the session mode. Rather than
failing silently, turn the item insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
Unaccelerated deltas make sure the gesture works the same regardless of how
fast the fingers move; this is what we were already doing for scrolling.
Remove the swipe multiplier as the deltas already match scrolling other than
the 1/10 multiplier Clutter applies to scrolling specifically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1763>
Since commit 3fb02843, we no longer skip allocation for
results that don't fit the width, and give them a 0x0
allocation instead.
That has the unintended side effect of those children now
being available to keynav. There are cases where we want
0-sized actors to be part of the focus chain (e.g. FocusTrap),
but this isn't one of them, so explicitly exclude 0-sized
children from keynav.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4470
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1916>
Destroying the source from an action callback will result in the
notification being destroyed twice:
- source.destroy() destroys all its notifications
- a notification destroys itself after an action
was activated
This results in unwanted log spam when attempting to dispose the
notification for a second time.
There is actually no good reason for destroying the source explicitly,
as sources already self-destruct with their last notification.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4457
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
Currently we only mark the banner as removed if it is destroyed
while in SHOWN or SHOWING state, but not if we're already HIDING
(for example in response to `NotificationBanner::done-displaying`).
If this happens, we'll try to destroy the notification again at
the end of the transition, which leads to (harmless but annoying)
log spam since Notifications were turned into GObjects (that are
disposed when destroyed).
Address this by always marking destroyed banners as removed, while
still only triggering a state update while shown (or in the process
of being shown).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4457
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
These do some some signals connection and monitor layout tracking
that we forget to disconnect when the magnifier is disconnected.
This causes warnings if enabling the magnifier, disabling it,
switching to another tty, and back. (Presumably also happens for
monitor hotplugs).
This signal should just stay connected as long as it's needed,
so add a setEnabled() method on the CrossHairs actor that we
can hook on the magnifier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1902>
Some popovers like the ibus candidate popover may be requested while
showing an unredirected fullscreen window. Disable unredirection
while the popover is visible so that it can actually be shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1900>
When implementing a D-Bus method synchronously, regular JS methods are
used. That is, whatever the method returns is passed as return value
to the method invocation.
However for asynchronous implementations, we need to explicitly return
a value to the invocation, otherwise the caller will wait until it times
out eventually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
The appDisplay used to be accessible via the viewSelector, but
that is gone now. Commit c09c070b15 adjusted the code, but the
replacement uses a Main.overview.appDisplay accessor that never
existed, whoops.
Fix this by exposing a new selectApp() method directly on the
overview, so we don't have to shuffle the appDisplay through
controls → overviewActor → overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
With Xwayland started on demand, mutter/gnome-shell will spawn Xwayland
and GNOME settings daemon Xsettings.
Currently, gnome-shell uses a timeout of 5 seconds before canceling the
launch and declare failure to start X11 services.
While 5 seconds may seem like a lot of time, when this is executed on a
virtual machine part of a QA tests under load, this causes random
failures.
There is no good value here, we could increase the timeout but it will
always remain racy. Instead, remove the timeout, systemd itself already
has a timeout mechanism (with a much longer wait time).
Thanks to Benjamin Berg <bberg@redhat.com> for finding the root cause
and suggesting the fix.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1888>
Right now we pop the modal immediately when closing, so the key-release
event of the Escape key ends up in the focus window which may consume it
for leaving fullscreen mode or similar.
We can avoid that in many cases by keeping the modal grab until the end
of the transition, as the key-release event will then likely occur while
the grab is still in place (provided animations are enabled).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1880>
org.freedesktop.impl.portal.desktop.gnome will be used for the
GNOME implementation of desktop portals in the future, so make
sure GNOME Shell's implementation of the access portal won't
conflict.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1872>
Another trivial cleanup. This is in preparation for next commit, that
will expand on this if clause, and will make it a bit more complicated.
Using a variable here makes it easier to read.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
Often, when using multiple monitors, the thumbnails box may be
destroyed before the 'hidden' signal of the Overview is emitted,
which leaves a bunch of lingering signal connections to the
workspace manager.
Call this._destroyThumbnails() in the _onDestroy handler, which
disconnects from workspace manager. This fixes the some of the log
spam that GNOME Shell produces with backtraces of destroyed actors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1860>
On systems/setups not using systemd, a failure to start gsd-xsettings
with NOT_SUPPORTED does not denote a failure to start Xwayland, just
that we're not using systemd.
In that case, we should just ignore the error, otherwise it will prevent
Xwayland to start on such systems/setups without systemd.
Thanks to Rose Kunkel (@rosekunkel) for spotting the issue/suggesting
the fix.
Fixes: 019229c40e - windowManager: Return failure to start X11 services
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4284
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1850>
Currently, handling of touch devices in the app grid is a bit awkward,
paging by dragging the view can only happen if started from the gaps
between icons, trying to drag from an icon will trigger DnD, and popping
up the menu takes over it all.
Instead, have the app grid actions play this game of rock-paper-scissors:
- Fast swipes on icons trigger scrolling, beats DnD and menu
- Slower press-and-drag on icons trigger DnD, beats scrolling and menu
- Long press triggers menu, beats scrolling, is beaten by DnD
This allows quick swipes to handle navigation, while still allowing the
fine grained operations. DnD, when triggered, dismisses the menu, if
shown.
This all could probably be nicer with a more stateful gesture framework,
we're not there yet though.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3849
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
This setting (by default, 0) sets a time threshold in order to allow
DnD. If the drag is shorter than this threshold, DnD will be cancelled,
and event handling left to the next handlers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
The switcherPopups use _next() and _previous() to get the items
in the text direction. I. e. with LTR _next() gets the right item;
on RTL it gets the left item. This doesn't work well with RTL when using
the arrow keys since the text direction doesn't matter in those cases.
Pressing Left Arrow should still move left regardless of text direction.
So use the opposite methods.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1835>
If for some reason the xserver failed to start, mutter/gnome-shell
should not attempt to connect to the X11 display otherwise it will
lock up in XCB.
An indication of such a premature failure of the xserver is when the X11
services fail to start.
Return the status so that the caller can cancel the connection in time
and avoid the lockup of mutter/gnome-shell in case of failure.
This, however, makes the X11 services a critical component to start
Xwayland, meaning that a failure to start those services for any other
reason than the xserver failing to start would still prevent Xwayland
and therefore X11 clients to run in Wayland. This is however a lesser
issue than mutter/gnome-shell locking up.
This basically reverts commit a96753f0 - "windowManager: X11 can work
without gsd-xsettings".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1837>
Change behavior on pressing Super+Number in Activities/Overview mode
so that the overview mode is hidden and application can be used.
This makes it consistent with clicking icon in the dash.
Closes: #4212
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1839>
Previously the workarea was only set on construction and then never
updated. As a result the preferred width and height as well as the
allocation were based on an outdated workarea size when it changed after
construction. This for example was happening during the startup
animation, for which the WorkspaceLayout is constructed before the panel
is shown. This caused the workspace in the overview to be slightly
smaller when it is first shown and the overview closing animation to
not expand the workspace to the correct size the first time it is
closed.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3945
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3816
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1771>
In the nested session the startup animation sometimes fails, weirdly
that always happens to me when running a freshly built gnome-shell the
first time. The reason it fails is that mutter fails to aquire a pointer
grab from the xserver, XIGrabDevice() is unsuccessful.
A simple workaround for this race condition in the xserver is to just
grab the devices a bit later, that is after the startups animation
instead of before it.
This was also tested with disabled animations, and seems to work just as
well in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1812>
Some drag actor parents might change their width to 0 after the drag
actor has been removed. If the drag is now canceled and the drag actor
is animated to return to the current parent position and scale, this
scale can not be determined and falls back to 1.0. This might be wrong
and can result in the drag actor being too large/small at the end of the
return animation.
To avoid this calculate the scale of the parent by recursively
calculating the product of its parents individual scales.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4017
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1790>
We want to clip the Workspace actor in the appGrid state of the overview
in order to make sure windows that overflow the monitor don't spill out.
So far we had commit b1970b95b8 for that.
Now since the last commit, window previews always slightly overflow the
allocation with their icons. That means a part of the window icon gets
clipped away as soon as the transition to the appGrid starts, which
looks weird.
Fix that bug in the transition by slightly extending the clip downwards
when animating between the window picker and the app grid state. The
extra height we extend the clip by is controlled by the overviewState,
which means we extend the clip by the full icon overlap in the window
picker state, but don't extend the clip at all when in the app grid
state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
We want to use as much space as possible for showing window previews in
the overview, and the title and close buttons of those windows are only
visible on hover, so we can show them above anything if we want.
On both primary monitors and secondary monitors, there's a certain free
space available towards the bottom edge of the monitor (on the primary
monitor we show the dash there, and secondary monitors just scale down
the Workspaces). We can make use of this by checking how much free space
there is available from the bottom edge of our allocation to the bottom
edge of the monitor, and then aligning the window previews to make full
use of this space.
So stop adding any padding to the edges of the Workspace, which will
make the windows a lot larger and completely fill the Workspaces
allocation.
The left, top and right monitor edges should always be far enough away
to accomodate the close button and hover scale-up of the window. Only
with the bottom edge of the monitor we have to be a bit more careful
(the overflowing height of the window title is quite big), so there we
check if enough free space is available. If there isn't enough free
space, we simply apply a bit of bottom padding again and shift the
window up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
Make the SecondaryMonitorDisplay a bit more similar to the
ControlsManager container on the primary monitor, and clip that widget
instead of the WorkspacesViews on secondary monitors.
This will allow us to overpaint the WorkspacesView allocation and paint
the WindowPreview overlays like the title and close button outside the
allocation with the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
The original parent of a dragged actor might have been destroyed after
the drag has been started. When the drag is canceled and _dragOrigParent
is set, the code is trying to get the current position and size of it
when restoring. With a destroyed parent this however would result in a
crash.
This could happen for example when starting a drag on a window preview
while the overview is hiding and then releasing it once the transition
is done.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4024
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1817>
`ThumbnailsBox` listens for the `showing` signal from the `Overview` to
create its thumbnails and destroys them on the `hide` signal. Since the
`showing` signal can be emitted multiple times when switching between
the shown and hidden state without ever fully completing the transition,
this will cause `_createThumbnails` to be called multiple times, each
time adding another set of workspaces.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
When starting a gesture to open the overview while a transition to hide
the overview is running, Overview._shown will be first set to false when
starting the transition and then to true by the gesture before the
`onComplete` callback is called. The `onComplete` callback in this case
is `Overview._hideDone()` which starts a transition to show the overview
again which also emits the `showing` signal. Since the gesture emits a
`showing` signal as well, this results in two consecutive `showing`
signals without a `hiding` signal in between.
This breaks the `searchControler` which adds a key press handler to
start the search on `showing` and removes it on `hiding`. So every time
this happens a new handler that will never be removed is added,
resulting in the first key press being repeated.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4004
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
When we press a key with variants, we used to prevent an
early ::pressed, because a long press could show the options
popover, and the press be undone.
In addition, this long press could move to one of the suboptions,
and be released there. For this case we also want this late
emission of the ::pressed signal.
This makes the "tap, drag, release" pattern work on the
regular OSK keys, in addition to the emoji panel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
This is already allowed for pointer events, but touch events still expected
that the touch begin and end happen on the same Key actor. Change this
behavior for touch events, this is necessary for the tap-drag-release
pattern to select key variants to work on all input devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
When super is pressed again during the overview transition, we shift
up to the app grid. That means that the feature currently doesn't
work when animations are disabled (like in a VM), because there is
no transition in that case.
Address this by adding a time-based fallback in that case, i.e.
shift up when a second super-press occurs within 250ms after the
first one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4121
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1811>
Using the callback directly as signal handler means that it will
receive the signal parameters (in this case: the StButton instance
that emits the signal).
This leaks an implementation detail that is harmless in the best
case, but can break dialogs when using bind() on the callback.
Avoid that trap by explicitly calling the callback without arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4139
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
