Since we correctly call the `style_changed` vfunc superclass at the end
of our own function anyway, the style changes will get propagated to the
children of the scrollView inside `st_widget_real_style_changed` anyway.
So remove those unneeded and quite expensive (because they cause the
theme node to be regenerated) calls to `st_widget_style_changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
Properly compare the new icon properties of StIcon to the old ones on
style-changes and only update the icon texture in case something
changed. This should help reduce the amount of texture cache requests
when we start emitting all "style-changed" signals again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
This makes it easier to track size changes when the paint scale changes,
since in those cases we basically want to do the same thing as when the
normal icon size changes: Request a new texture from the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
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>
We'll likely have to interact a bit with the newly added Meta.Context
object, so add a convenience property that gives us direct access
instead of getting it from the display every time we need it.
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>
This job does:
1. Download the coverity bundle and untar it in a cached location
2. Build GNOME Shell using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis
In a similar setup to that of Mutter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
It was on one hand using multi-line piping (`|`) and trying to
compensate with \ to escape multiple lines, this lead to:
No match for argument: \
Also, the quoting around pkgconfig() arguments would lead to
double quoting at the shell level, thus:
No match for argument: 'pkgconfig(gio-2.0)'
Fix both by using multi-line-turns-single-line piping (`>`)
and dropping the unnecessary quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1913>
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>
This ports over gnome-shell and the theme test case to MetaContext,
instead of the various functions that were available before.
The test case is changed to use the special test context, used to
construct contexts for testing. It's part of a shared libary separate
from the main libmutter one.
This enables building mutter tests during CI, as the test framework is
needed by some of gnome-shell's tests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1840>
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>
