The windows we create use a simple pattern as content, as that's
easier to follow than completely empty windows. GTK4 no longer
allows hooking into the drawing of arbitrary widgets, so prepare
for that by using a dedicated subclass instead of a signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
We are about to port the helper proxy to GApplication, which means
that it will establish a display connection before exporting its
D-Bus name. That means that the compositor must be able to respond
to a roundtrip request to avoid locking, so don't block on the proxy
becoming available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
There's another remaining bit of Gtk3 code in a small test program
that changes a window title to a random character sequence every
five seconds. While the value of that test is a bit questionable,
it doesn't hurt either and a port is trivial.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
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>
