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.
