Commit ee0538807 restored the fixed password entry width, but only
for entries nested under .prompt-dialog-password-layout. That
does not include the network secret dialog, so go back to the
original styling prior to commit 8d065b558e where the width
is set for all password entries, and the mount operation overrides
it with a more specific rule.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3514>
Commit removed the fixed width that is used by polkit/keyring
prompts, with the result that the entries now start at their
natural size, and grow as text is entered.
Restore the original behavior, but nest the style under
.prompt-dialog-password-layout (polkit/keyring) to better
differentiate it from entries under ..prompt-dialog-password-grid
(mount operations).
Fixes: 8d065b558e ("style: Clean up dialogs stylesheet to fix layout issues")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3511>
- remove unnecessary dialog type-specific padding, spacing and margin definitions that led to layout to problems
- bump the size of user avatar in authentication dialog
- nest css classes in the sass to better reflect the structure of dialog elements
- sync style of audio device selector with switcher-popup style
- sync text and padding styles with other elements
- fix incorrect button order in audio selection dialog
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7876
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3473>
The offset in high contrast mode was moving the dot too close to the
text making the spacing between the text, dot and hover highlight appear
visually unbalanced. Also it was making it more likely to overlap
descenders in the text.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
With the dot now being placed correctly at the bottom of the hover
highlight it is now also overlapping the 1px inset shadow used as
outline in high contrast mode. To avoid this, shift the dot up
accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
The dash currently doesn't enforce any spacing when it comes to the left and
right edges of the monitor. With the right amount of icons, it will come
very close to or even touch the edge.
Make sure this "edge case" also looks good by adding a padding to the left
and right of the container.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
With the addition of notification headers, we no longer include
an icon with every notification, but only when the notification
explicitly specifies an icon (other than the app icon).
After those changes, it makes more sense to use the icon as
provided by the app than forcing the symbolic style (which
only works for themed icons anyway).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7620
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
Stop using custom buttons for notification actions. The only reason to
use custom buttons was so that we could add icons next to the button
label, if we really need the icons next to the label we can add icons to
the notification API.
By using the actions API we can ensure that buttons always look the
same without additional work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Its parent `lockDialogGroup` has exactly the same background-color
set in the same file. Giving them both the same wasted render time on
overdraw, and caused multi-layer blending artifacts (slight flickering
of the grey background) when the login dialog fades in/out.
While the flicker can also be fixed using `set_offscreen_redirect`,
there's no point adding that overhead when the extra layer doesn't need
to be painted. Removing it halves the average render time of the login
animation.
Closes: https://bugs.launchpad.net/bugs/2036388
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3207>
This is to make it generally more in line with the stylesheet as well
as to resolve the blue and white bleeding together in dark mode.
It's also consistent with switches in recent mockups.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3077>
