With the transparent top bar in the overview, constraining to the
primary monitor's workarea causes the (now visible) area beneath
the top bar to not have the darker background, which causes a visual
discontinuity in the layout.
Don't constrain to the primary monitor workarea.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1590>
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>
This is some leftover from code that was used to keep track of volumes
added/removed while the screen was locked before the move to a
components system in 2a800e4c. All that the remaining code does is
filter devices from an empty list.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1579>
Now that the Dash is horizontal, the popup menu of the Dash icons must
show up, instead of left/right.
Make AppIcon.popupMenu() receive an optional parameter with the side
to show the menu, using St.Side.LEFT as default. Override this method
in DashIcon to always pass St.Side.TOP.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
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>
Like the mutter 40.alpha.1.1 release, we missed adjusting to a
GSettings schema move from g-s-d to gsettings-desktop-schemas,
resulting in an abort on startup with the latest released
gnome-settings-daemon.
Between the GTK4 port and the latest GTK4 version, calling realize()
on a newly created window to force its surface to be created stopped
working.
So instead, wait for the window to get realized regularly to set its
parent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1574>
The shader code currently only accounts for padding for the
bottom and right fades, but not for top and left.
As a result, we only fade the right edge when swiping through app
picker pages, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1569>
With the previous preparations in place, it is time to take the plunge.
As both the app and the portal use the same small library for handling
external windows, port everything at once to avoid the hassle of building
and installing two versions of the library.
With the portal using GTK4 now, all extensions must port their preference
widgets as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
We currently use separate frames for the details expander and the
expanded details. That layout works as long as frames are boxy (as
in the default GTK3 style), but breaks down with rounded corners
(as in the default GTK4 style).
In order to work with either style, adapt the layout to use a single
surrounding frame and appropriate borders as separator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
GTK4 will remove the GtkHeaderBar:title property, so stop using it
and set the window's title property instead, as that's what headbars
use in both GTK3 and GTK4 unless explicitly overridden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
There's little point in setting properties to their default value,
so stop doing that.
(GtkFrame:shadow-type actually defaults to "edged-in" rather than "in",
but all types other than "none" are treated the same nowadays)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
Unlike in previous GTK version (or Clutter), destroy() no longer
breaks reference cycles but just releases the reference held by
GTK itself.
So any reference we hold - either the explicit property or any signal
handlers that bind the window as `this` - prevents the window from
being disposed when closed, and the application won't quit.
Work around this by explicitly running dispose() on the window when
it is removed from the application.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
GTK4 will remove the GtkHeaderBar:title property, so stop using it
and set the window's title property instead, as that's what headbars
use in both GTK3 and GTK4 unless explicitly overridden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
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 SHADE_ANIMATION_TIME variable sets the duration of the animation of
the background shading that is done when showing the overview. As
explained in the code-comment, that value must be smaller than the
animation time of the overview.
Now since we're going to start animating the background color of the
panel when showing the overview and we're going to use the overviews
animation time for that, we want to make sure the shading of the
background image and the animation of the panel are kept "in sync",
otherwise the transitions would look bad.
So slightly increase the value of SHADE_ANIMATION_TIME to 240 (the
overviews animation time is 250) to make sure those happen in the same
timeframe.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
