Its only purpose is to provide a test case for the remote app menu,
but that support was removed in gnome-shell years ago. We don't
need a test case for GTK's fallback app menu support, so remove
the whole thing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
Now that we track apps instead of instances, we can make the menu
items activatable, because the corresponding action is no longer
app specific (like activating a particular tab): We can simply
activate the app, which hopefully will bring it to the foreground
again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
The background apps menu currently tracks instances rather than
apps. That matches the behavior of `flatpak ps` and can be useful,
for example when one particular instance runs out of control.
But as we don't include any information that allows to actually
distinguish between instances, multiple instances appear simply
as duplicated app entries.
Given that a menu is too limited for detailed information, stop
representing individual instances, and track apps instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
Provide a reasonably public way to register and unregister search
providers, without adding too much API.
`Main.overview.searchController` provides access that may be generally
useful, while `SearchController.addProvider()` and
`SearchController.removeProvider()` provide a simple interface for
extensions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2783>
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>
