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>
Commit ca4f6e0123 was supposed to show the
"cellular-disabled" icon when wwan is disabled. For wwan, just like for
bluetooth wwan networks, we probably want this to include the "not
connected" state, because disconnecting from cellular service de-facto
means disabling it.
So switch the check to show the "cellular-disabled" icon to also use the
icon whether there's no active connection, not only when the wwan device
is turned off.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5401
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2283>
The layout manager of the calendar/notifications popup is using the
calendar width to determine the width of the whole right area of the
calendar popup. When enabling large text, this means the cards used for
world clocks, weather etc. get larger, while the calender doesn't get
larger, leading to the cards getting clipped.
Make sure the calendar grows in size just as the cards do when large
text is enabled and define its size in em's instead of pixels.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5392
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2282>
The swipeTracker wants the distance between two pages passed to it in
confirmSwipe(). In case of the app grid, the correct distance is not the
size of the scrollView (which has the width of the whole screen), but
instead the allocation size of the iconGrid (which is the actual size
of a page in the grid).
So pass the allocation size of the iconGrid to the swipeTracker, this
makes sure the pages move perfectly in sync with the pointer when
dragging using the mouse or touchscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2275>
With commit c29e0cf6e6 the grabHelper
already started using a similar mechanism to funnel events to the osk
while a ClutterGrab is in effect. ModalDialog, the unlockDialog and
lookingGlass don't make use of the grabHelper though, they use
Main.pushModal() themselves, so those need to funnel the events to the
OSK themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2263>
