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>
This bumps both the mutter image to the F34 one, as well as the one used
for review.
This also bumps ci-templates hashes, so that we can use
FDO_DISTRIBUTION_PACKAGES without installing weak dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1906>
`mallinfo` has been deprecated in favor of `mallinfo2`:
```
The fields of the mallinfo structure that is returned by the
older mallinfo() function are typed as int. However, because
some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1786>
It's not visible because it's covered by the actual wallpaper, so
not rendering it eliminates most of the render time for
`workspace-background`, without changing its appearance.
When animating the overview by tapping Super, this reduces the
shell's overall render time by about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
Until now, the absence of a `background-color` would cause `box-shadow`s
to be invisible. That was a bug because `box-shadow` is meant to be either
the color specified in `box-shadow`, or if none was specified then the
foreground `color`.
There is nothing in the spec that says the `box-shadow` rendering should
depend on `background-color`, so separate them. This ensures `box-shadow`
is rendered even when `background-color` is absent or transparent.
https://www.w3.org/TR/css-backgrounds-3/#box-shadow
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
From [the spec](https://www.w3.org/TR/css-backgrounds-3/#shadow-blur):
> the resulting shadow must approximate (with each pixel being within 5%
> of its expected value) the image that would be generated by applying to
> the shadow a Gaussian blur with a standard deviation [sigma] equal to
> half the blur radius
This does not change the value of `sigma`, it only corrects the value of
`sampling_radius` used to size the shadow texture. Since the texture is
no longer being slightly oversized it won't get scaled down when rendered
according to the dimensions provided by `st_shadow_get_box` in
`_st_paint_shadow_with_opacity`.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4409
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
Having an inaccurate paint volume didn't matter until ae338af1e8, but
after that having too small a paint volume resulted in apparent clipping.
Not because `clip_to_allocation` is set, but because the offscreen
framebuffer is sized to fit the paint volume only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
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>
The migration happened in GNOME 3.6 over 9 years ago. The chances
that someone migrates from 3.0.x or 3.2.x to 41 are very much zero.
And if it were to happen, it wouldn't work anyway, because we stopped
using a separate overrides schema.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1890>
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>
When a GTK app is started, we create a corresponding GtkApplication
proxy to monitor the app's busy state. If the app is stopped before
the proxy request finishes, we cancel the cancellable before clearing
the running state.
Usually we clear the cancellable once it is no longer needed, namely
when we got the proxy. However when the request was cancelled, the
cancellable has already been cleared, and if there's a cancellable,
it belongs to another request (because the window was added again,
for example when moving between monitors).
Leave that cancellable alone in that case, so we can cancel the
second request as well if necessary to avoid a crash when trying
to set the proxy on a cleared running state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1885>
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>
