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>
Despite this grab happening in the dialog, we are also interested in
things happening outside of it. Move this grab to happen in the stage
itself, so the changed grab semantics don't make it impossible to
interact with parts of the login screen.
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>
