When ClutterImage got merged into StImageContent with commit 64d5d01360
("st: Merge ClutterImage with ImageContent"), a small error slipped in when
copying over the update_image_size() function.
Within ClutterImage, update_image_size() served a simple purpose: To call
clutter_content_invalidate_size() in case the texture size would change.
To check that, ClutterImage was storing the existing texture size in the
priv->width and priv->height fields.
When merging into StImageContent, those priv->width/height fields happened
to overlap with priv->width/height of StImageContent, but there they are
storing the preferred size, rather than the texture size. Copying
update_image_size() as-is into StImageContent meant we now set the
preferred size to the texture size, subtly breaking resource-scaled StIcons
(where texture size is a multiple of the preferred size).
The breakage isn't very apparent because StIcons manually set the size
of their internal ClutterActor child to the requested icon-size via
clutter_actor_set_size() in st_texture_cache_load_gicon(), and that makes
the child actor report the correct size in get_preferred_width/height(). The
child actor gets allocated via clutter_actor_allocate_align_fill() from
ClutterBinLayouts vfunc_allocate(), and clutter_actor_allocate_align_fill()
honors both the available size from the parent and the CONTENT_SIZE
request-mode on the child. So when the StIcon has a larger allocation (aka
extra available size), clutter_actor_allocate_align_fill() will fill that
available space with the (too large) content size.
To reproduce the issue, on a resource-scaled monitor, simply create an
StIcon with a fixed width and height that's larger than the icon-size. The
icon will be painted too large and blurry.
Fix this fallout by avoiding to touch the priv->width/height properties on
StImageContent, and instead simply comparing old texture size to new texture
size, we have both textures around after all!
Fixes: 64d5d01360 ("st: Merge ClutterImage with ImageContent")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8287
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3680>
The DBus PreparingForSleep property on org.freedesktop.login1.Manager
does not trigger PropertyChanged signals, leading to wrong values due to
gdbus caching. In most cases it would have always been false.
Additionally it was not included in the XML interface description file
included in gnome-shell. So it was actually undefined.
Since this property is used in _calculateUserStateFromLogind() to
determine that a user is not active when closing the lid on a laptop,
the user was considered still active.
Fix this by storing the "start" argument from the PrepareForSleep signal
instead of trying to read from the property.
Fixes: 6a43b6f55 ("timeLimitsManager: Store screen time state on suspend/resume")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3679>
Since the handle radius is used to calculate the width and height of the
slider, having the calculated size be a non-integer value can cause the
following widgets in a box-like container to be unaligned with the pixel
grid, which can lead to blurriness or other visual issues.
This for example could be observed with the interface font set to
"Cantarell 12", which results in a handle radius of 8.278. In quick
settings when showing two consecutive sliders, the second slider then
gets rendered at a non-integer vertical offset.
Further having a non-integer size for a StDrawingArea can cause the
texture to get slightly squished or stretched as the size of the cairo
surface is rounded to the nearest pixel, but rendered using the
unrounded actor size.
This commit changes the border radius rather than ceiling the preferred
width/height so that the handle size always matches the width or height
of the widget and there are no visual gaps caused by a partially filled
pixel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3648>
Using the ceiled radius for calculating the rightmost position the
handle can take on the slider was resulting in a small gap when the size
was not an integer value since the radius used when drawing the handle
is not ceiled.
This effectively reverts 38da479e which seems to have been the wrong fix
for the problem it was trying to solve. The problem presumably had been
caused by not considering the border that the handle still had at that
time.
The border issue was then later fixed by 3ddae9d8, without reverting
38da479e. Then in 6fd0aac8 support for drawing borders on the slider got
dropped, including the changes from 3ddae9d8, leaving us with just the
changes from 38da479e but now without borders on the handle.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8187
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3648>
There is always at least one workspace context which is the context
that is currently being used by the GNOME desktop. If no running realm
is associated with this context then we consider this context to be
'detached' and store it so that the next time a context is needed to
attach to a running realm, this 'detached' context will be used rather
than asking mutter to create a new fresh context.
