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>
When trying to connect to a network from gdm, it doesn't make sense to query
secrets from the gdm user since it's a system user.
Furthermore, gdm runs an isolated dbus-session per gnome-shell instance
(for multi-seat setups). Instead, gnome-keyring-daemon is started by systemd
and so it registers on the _main_ dbus session of the gdm user session.
Then, gnome-shell tries to dbus-activate another gnome-keyring-daemon on its
isolated bus, but gnome-keyring-daemon refuses to start as it sees another
instance already running, exposed at $XDG_RUNTIME_DIR/keyring/control.
After a 25s timeout, gnome-shell aborts the request without ever prompting
for a new password.
Because it is both problematic and pointless to query secrets in this case,
let's avoid it altogether and just prompt the user for the network password.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3646>
We currently create the default folder with the corresponding
app list, regardless of whether the apps are actually part of
the default install or not.
This matters when a user explicitly install such an app later,
as it will be hidden away in the folder rather than appended
to the app grid as expected.
To avoid that, only add currently-installed apps to the folder
when creating it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
When there are 3 or more windows in WorkspaceLayout, showing or hiding
window preview overlay in some certain orders could cause
inconsistencies in windows' vertical arrangement.
Let's take window A, B, C as an example. Initially, A is above B and B
is above C in workspace layout like this: A -> B -> C.
After opening activities, user could:
1. Move cursor to B preview, which would move B above all in layout:
B -> A -> C
2. Move cursor from B to C preview. When C's showOverlay() is called
before B's hideOverlay(), _restack() would move C above all and don't
change B's arrangement:
C -> B -> A
3. Finally, move cursor away from C's preview:
B -> A -> C
In this case, when user closes Activities, they would see window
stacking wrong for a while.
This commit adds some extra logic in _restack, checking the
_stackAbove's _stackAbove when this._stackAbove._overlayShown is true.
Though it's still not guaranteed to be always consistent as there could
be several WindowPreview with _overlayShown as true if pointer moves
really fast, this helps avoid glitches in many cases.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4638.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3460>
The new design requires that other messages and groups are faded when the user
has a group expanded. This introduces a new GLSL shader to provide the
desired effect. The new shader is used for the already existing scroll
fade and the previous one is removed. The two fades need to work together to
ensure that resulting fade looks good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
We need to track message order separate from the widget children order,
because of how notification groups will add a cover over other messages
when a notification group is expanded that will prevent interaction with
any message other then the expanded notification group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message grouping by source we need more control over the list of
messages to reflect this change rename the MessageSection to
MessageView. Message from different sources will be added to the
MessageView directly in a future commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message/notification grouping by source we need more control over
each single message therefore in a future commit the
MessageListSection will contain all messages directly instead of having
a separate section for different source (notifications and media).
The lost NotificationSection and MediaSection will be readded in a
future commit as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
