When calculating the on screen coordinates of events from the window
relative coordinates, using the frame rect will include the decorations
added by the WM for SSD windows. This was causing the calculated
coordinates to be slightly off. Fix this by using the client rect for
SSD windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2319>
Absolute screen coordinates are impossible for Wayland clients to
provide, because the clients don't know where the window is positioned.
Some clients, such as the ones using GTK 3 were providing window
relative coordinates even when screen coordinates were requested,
while others, such as GTK 4 clients, were just returning an error for
caret events or also window-relative coordinates for focus events.
So for this to work on Wayland we have to request window-relative
coordinates and translate them to the current focus window.
To ensure the correct coordinates, we have to only consider events
coming from the current focus window. All other events are filtered out
now. As a side effect this also fixes the magnifier always jumping
to a terminal cursor whenever there was some output, even if the window
was not focused.
This also needs some special handling for events coming from the shell
itself, which should not be translated to the focus window either. As
another side effect this fixes another bug that was caused by these
events already including scaling and getting scaled again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5509
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2301>
If we don't set the height property to -1 before requesting the
preferred height, get_preferred_height() will just return us the fixed
height that has been set before. We don't want this behavior here, so
set the height to -1 before calling get_preferred_height().
This fixes a resizing issue where the keyboard is sized incorrectly
after switching the monitor into portrait mode and back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2306>
Both bluetooth and screencast support are based on build checks
right now. However in both cases, the dependency is only consumed
at runtime via the typelib, so let's actually check for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
We currently decide at build time whether to include screencast
support, based on whether the required gst/pipewire library headers
are installed.
That check is imprecise, because having the library headers available
at build time doesn't necessarily mean that the libraries are there
at runtime, or that the corresponding typelibs are installed.
It makes more sense to check the requirements at runtime, so prepare
for that by installing the screencast service unconditionally, but
bail out early if the dependencies aren't met.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
The problem is that " 9:59 AM" (notice the space at the beginning) and
"12:59 AM" strings, when centred, look misaligned —
strings padded with a space look off to the right by nearly
half a character. This happens because the font feature "tnum",
used to make numbers monospace, doesn't work on spaces.
The commit overcomes this by aligning time labels to the end.
However, this won't work for locales with AM/PM strings of different
lengths, so they are aligned to the start instead to minimise offset.
It's too complex to know whether the used locale has different
AM/PM string lengths. Instead, every time the time changes, it
determines whether all the time labels have the same amount of characters.
Fixes#5438
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2294>
We update the visibility on state or stream changes, but those
changes may never happen if pipewire-pulse/pulseaudio isn't
available (for example when running as root).
Hiding the sliders is preferable in that case to showing non-working
controls.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2295>
GTK4 added a convenience property for icon-only buttons. While that
use case is not quite as common in the shell as in GTK apps, it still
seems common enough to mirror the GTK API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2254>
When selecting the largest possible icon size for restricted vertical or
horizontal space the options for low resolution icons were rather coarse
grained. This could often result in seemingly too small icons being
chosen in the app grid on systems with low vertical resolution, because
the next larger size would exceed the limit by a few pixels.
This adds two more commonly used sizes for application icons to have
some more options with restricted space.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2173
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2289>
Commit 7419674b changed some grabs from requiring both mouse and
keyboard grabs to be considered successful to only requiring either of
them.
Due to this it was possible for example to open the overview or the
screenshot UI with a client (such as Chrome when opening a menu) holding
the mouse grab. This then made it impossible to interact with the UI
using the mouse (or keyboard) and if attempted could result in an
unresponsive UI.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5414
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2287>
