We started to support Soup3 in GNOME 41, and used it by default
since GNOME 43. This should be enough time for distros to adapt,
so GNOME 45 looks like a good moment to drop the old Soup2 support.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2776>
Since we started to support the color-scheme preference, extensions
should be able to provide appropriate variants (if they deal with
colors).
So look for a variant with -dark/-light suffix before using the
plain stylesheet.css, and reload extension stylesheets on
color scheme changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2324>
The IBusCandidatePopup can get 'stuck' in an active, visible state if
it is on-screen at the point when the input method is changed to a method
that doesn't use such popup (e.g. regular English).
Force the candidate popup to close when the engine is changed.
It will reappear (via regular lookup table update signal) if/when it is
next required.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6717
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2774>
Out of the box, the container images only support US English. It
can sometimes be necessary to use a different locale, so add
a convenience flag to enable support for additional locales.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The container is useless for building or running gnome-shell unless
it includes the correct mutter version, so building it by default
makes sense.
However a manual build can be significantly faster when there's an
existing build dir, so add an option to skip the automatic build.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
A toolbox created by the script can be used as the base of a pet
container that is manually updated with new dependencies over time
and accumalates additional packages; or it can be used as a deposable
container that is recreated each time the dependencies change.
To make the latter case more convenient, add a --replace option
that deletes an existing toolbox before creating the new one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The script is a thin wrapper around `toolbox create`, mainly to
avoid the tedious image names. In addition, it allows us to
ensure that the container includes a matching mutter version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
Toolbox is a convenient option for development, but setting up
the image with all dependencies is annoying at best, in particular
later in the cycle when `dnf builddep` is likely insufficient.
To address that, produce toolbox images for main and stable branches
that are based on the regular CI image, and update them whenever
the image version is updated. This guarantees that all build- and
runtime dependencies are included.
Unsurprisingly, the script that produces the image draws heavily
from freedesktop's ci-templates. The most notable difference
(other than being neither distro-agnostic nor generic) is that
tag names are fixed (toolbox:main, toolbox:43 etc.) to make them
easier to consume.
Instead, whether an image needs rebuilding is based on a custom
label that records the base image that was used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The callback would schedule a clutter_actor_destroy() on the first
argument. Unless told otherwise, this is the same actor that is
already being destroyed, so this is a no-op.
Instead, the intent is to make the clone follow up destruction of
the window actor so that it results in correct removal of this
window from the ShellWindowPreviewLayout. Use a swapped connection
to pass the clone actor as the first argument of the signal callback.
Fixes: 04c781674c ("Move WindowPreviewLayout from JS to C")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6570
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2756>
Calling _teardownPipeline() before _tryNextPipeline() was actually not a
good idea, it sets the pipelineState to STOPPED, which means we can't try
any of the following pipelines anymore.
Instead what we want to do is set the pipeline state of the old pipeline to
NULL when trying a new one, without calling _teardownPipeline() for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2754>
Now that the app menu indicator is no longer shown, it shouldn't be possible
to toggle the popup menu via keyboard shortcut anymore, so remove the code
and gsettings definitions for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2610>
This pipeline imports dmabufs and does format conversion using GL.
The `video/x-raw(memory:DMABuf)` filter ensures format negotiation
between `pipewiresrc` and Mutter will only succeed if Mutter advertises
dmabuf support as well, falling back to the next pipeline otherwise.
Using this pipeline frees Mutter from downloading buffer content on the
main thread which can have a big impact on compositor performance.
Doing format conversion on the GPU should further improve the overall
performance on most hardware.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2597>
When the screencast dbus service crashes due to gstreamer, we should also
handle that and not pretend to continue recording.
Let's listen to g-name-owner changes for that and then also send a
notification about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
Make sure gnome-shell gets notified of errors that happen during screen
recording using the screencastService, so that it can properly notify the
user about the error and tear down its state, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
Pipewire versions < 0.3.67 may not fail immediatly on negotiation
errors, thus use the last/fallback pipeline directly.
Technically, a similar recent version of Wireplumber is required
as well, but we can't check that easily and the combination of old
Wireplumber and new Pipewire is quite unlikely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
Introduce a fallback mechanism for gstreamer pipelines that allows to
define multiple pipelines and prefer them over each other.
The way this works is that we introduce a new STARTING PipelineState.
While the Recorder is in that state, it is allowed to tear down the
current pipeline and start another one whenever an error happens, this is
used to try multiple pipelines in a fixed order until a working one is
found.
Right now there's just a single pipeline using the existing vp8 encoder, the
actual new encoders and pipelines will be added in a separate commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
The check for the Pipewire version was originally introduced in
d32c0348 which states:
> Since it is not clear yet when a proper solution will arrive,
> this makes use of `always-copy` as a workaround for now and
> should be reverted once it is no longer needed.
The check for a stable Gstreamer version with the mention proper fix was
introduced in d7b44319 and carried for the 43 cycle.
By the time Gnome 44 will be released all distros should have had enough
time to update their Gstreamer version - or backport the patches, in
case of not ustream-supported versions.
Thus lets drop it now.
Note: `always-copy` is not suitable for dmabuf buffers as it copies via
mmap.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
Right now when we tell gstreamer to move the pipeline to the state
PLAYING, we pretend that happens immediately and set our PipelineState
to PLAYING right afterwards.
In reality though it's more complicated than that: Gstreamer changes
states asynchronously and set_state() returns a Gst.StateChangeReturn.ASYNC.
In that case we should wait until the according STATE_CHANGED event happens
on the bus, and only then set our PipelineState to PLAYING.
Since the STATE_CHANGED event will also happen when set_state() returns
SUCCESS, we can use the same async logic for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
Gstreamer can produce various errors, we shouldn't pretend those don't
exist and go on as usual when one happens. Instead, when an error
happens, tear down the pipeline, set our PipelineState to the new ERROR
state and bail out with a proper error message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
