Use a bit less margin at the top and add some margin at the bottom of
the search entry. This should ensure the search entry is closer to the
panel than to the workspaces and avoid associating the workspace
thumbnails with the search instead of the window picker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
The Dash currently has a horizontal margin and a top margin applied. The
horizontal margin isn't necessary since there already is a horizontal
padding applied, and the top margin is a bit large, since the
ControlsLayout enforces a spacing between the different containers
already, so slightly decrease the margin-top here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
Depending on the available horizontal space, we may want to manipulate
the icon grid and scroll view spacing to result in an optimal layout
that has space left to preview prev/next pages.
The main change here is that, when adapting to the available size, the
space given to a page does not necessarily match the available space,
as we need to be able to show more than one page at a time.
With this decoupling of available and page sizes in place, we now know
how much space there is available in order to extend the padding between
pages, or the fade effect applied to the previewed pages.
Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more
on the StScrollView::content-padding property.
All put together, gives us proper space management from ultra-wide
displays, to display ratios that are close to the optimal grid ratio.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Remove padding on left and right of the contained widgetry, so
there's no seams animating things from the border. Also, remove
the padding between IconGrid pages, so the nest/prev pages are
visible given the dialog width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When DnDing an icon, we show both previous/next page, and optionally
a "placeholder" actor to allow creating new pages. These sides on the
scrollview are drop targets themselves, allowing to drop an app onto
the next/prev page without further navigation.
Still, preserve the checks to maybe switch to prev/next page without
finishing the DnD operation, for finer grained operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Add the necessary animations to slide in the icons in the previous/next
pages, also needing to 1) drop the viewport clipping, and 2) extend scrollview
fade effects to let see the pages in the navigated direction(s).
The animation is driven via 2 adjustments, one for each side, so they
can animate independently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
We want to show left/right side pages during navigation, also in
FolderViews. Let this scrollview use the same style than the "all
apps" one, and generalize the name a bit.
This will compress the scrollview horizontally, so there's actual
overflow space to show these pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.
That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
A small mistake snuck in right before landing the previous commit and
the box-shadow was moved 4px vertically above the wallpaper instead of
below it. Fix that and put it 4px below the wallpaper.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1697>
According to the GNOME 40 mockups, add a box-shadow to the workspace
background. For this to work, we also need a background-color (St
limitations), and to make sure that background-color doesn't bleed over
the rounded corners of the wallpaper, we also need to tell St to use a
border-radius and clip the background-color painting using a rounded
path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
When commit 3a9acb96 moved around padding to extend the clickable
area to the screen edge, it reduced the inner padding too much and
the running indicator ended up outside the highlighted area.
Adjust the padding to put it back into its place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1693>
In the future, we want to tightly control the state of the
layout throught gestures, which requires hooking everything
together with adjustments. This is the first step in this
direction.
Add a new custom layout manager for ControlsManager that
allocates the search entry, the view selector, and the Dash,
vertically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
We now set a padding for the left and right
side of the pill. We also got rid of the padding on the icon.
Probably broken due to the removal of the dropdown arrow
which likly handled the padding the right side of this item before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
This is the same color that the Dash currently has, except
it isn't transparent.
The reason for this change is that the app grid coming from
the bottom and passing below the Dash looks odd with the
transparency there.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Only the area used by favorite apps can be used as drop targets, it
is not possible to add new favorites between the running apps at the
end. While that behavior makes sense, it is currently impossible to
distinguish the two areas with confusing results.
Address this by adding a visual separator between favorites and
running apps.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1606>
When we display the hint string for e.g. (or swipe finger), the login
box gets pushed up. This is leftover from older styling and should be
removed. The padding-top is unnecessary and can also be removed, so just
remove the whole line styling login-dialog-message-hint from the
stylesheet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1582>
The code previously was using CSS to define row/column spacing and
padding which was combined with a subicon size computed in code relative
to the requested icon size.
In smaller icon sizes it was possible for the CSS spacing+padding + the
size of the two subicons to exceed the requested icon size. This then
would lead to the label being pushed down for app folders compared to
other icons.
Another more severe issue caused by this would happen if the first item
in an icon grid was an app folder. Then the calculation for the maximum
allowed icon size could be off, leading to all icons in the grid
becoming smaller than actually necessary.
This commit changes this to use homogeneous row and column layouts to
evenly distribute the remaining spacing instead of using a fixed CSS
value.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3069
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1581>
And move it to the bottom of the overview. Change the height-based calculation
of the icon sizes to be width-based. Put the DashFader in a vertical box, and
make all corners of the Dash equally rounded.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
The overview is using a heavily darkened background image nowadays.
Since the contrast provided by this is always good enough, this makes it
possible to always have a fully transparent panel while showing the
overview.
So change the theme to always make the panel fully transparent while the
overview is shown. The duration of the animation for that is 250ms
because that's the duration of the show and hide animation of the
overview.
Also add special handling for the high-contrast theme, where we always
make the panel opaque.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The current way of indicating focus of elements in the panel does not
work very well with a fully-transparent panel, a line at the bottom of
the panel doesn't make too much sense if there is no real panel, but
only the text and icons.
To make the indicators look better in this case, switch to a pill-shaped
background color to indicate the focus of items in the panel.
For this to look good, there has to be a small black border above and
below the background, this also requires increasing the height of the
panel (from 1.86em to 2.2em) for visual purposes.
Also, since we now no longer need to color the lower bottom of the
panel, we can remove the custom drawing code for the border of the
panels corner, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The activities button doesn't have an icon, which makes its horizontal
padding appear a bit smaller than the padding of most other items in the
panel.
We're going to indicate hover and focus of items in the panel using a
pill-shaped background color, which means the padding of those items
will get more visible. So give the activities button a special treatment
and slightly increase its padding to make sure the new indicator will
look good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
Recent commit [1] added a strong light border around user avatar
icons, in accordance with design mockups.
As a probably unintentional side-effect, the border was also added
around the symbolic fallback icon, which is displayed whenever the
user avatar is not available. This doesn't work well with the current
design, as the strong border makes the subtle fallback icon
background indistinguishable. Additionally, it doesn't match the
design mockups for the symbolic avatar icon [2].
Correct this by adding a style class for when avatar image is used,
and apply the border only for that case.
[1] 498710c2ec
[2] https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/lock-login/username-based-login.png
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1490>
The default sizing for user-icon style was not defined in the theme,
but it simply used the default Avatar iconSize from UserWidget.js.
This didn't work with the current fallback avatar styling (i.e. when
the avatar icon is not set for an user account, and a symbolic icon
is displayed in its place), as the fallback StIcon was not scaled
to align inside the circle shaped user-icon properly.
Define the user-icon and corrected fallback StIcon sizes in the
stylesheet to correct this. The default 64px user-icon size is based
on default UserWidget.Avatar iconSize. The sizing for the StIcon is
taken from `.user-widget.horizontal .user-icon` styling, which uses
the same base icon-size.
Additionally, the special `.user-widget.horizontal .user-icon`
styling is removed, as it is now redundant.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1490>
