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>
