- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
CSS and JS adapted from the Overview window close buttons, but with some
style tweaks requested by the designers.
Since the screenshot UI is long-lived (it's created once at startup,
rather than every time it's opened), we need to refresh the close button
position, as it can change at runtime. Subscribing to preference changes
seems to be skipped for bindings generation in Mutter, but simply
refreshing upon opening the UI should do the job.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4997
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2147>
This commit replaces a few of the screenshot UI CSS expressions with
named variables.
The shot-cast margin is not defined, but rather set to the value it ends
up equal to, given the panel padding and the capture button's
sizes + position, which would be a bit awkward to compute here. It ends
up slightly larger than the general panel padding due to the capture
button being larger than other elements, and due to having to
center-align the shot-cast container to the capture button.
The shot-cast container border radius is defined as 12px, then the panel
border radius is computed from the shot-cast border radius + margin,
then the type button border radius is computed from panel
border radius - padding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
Currently does nothing. When we're in screencast mode, we hide the
screenshot preview because screencast doesn't start until the capture
button is pressed.
The window selection is currently left as is, but it should probably be
changed to something closer to a real overview, showing windows in
real-time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
If a menu item in a submenu is part of a section, it should have
rounded bottom corners if both the item and the section are the
last child of its respective parent.
To express that, add a new .popup-menu-section class and use that
to undo/redo the rounding for items inside a section.
It would be possible to do without a new class with a selector like
> StBoxLayout > .popup-menu-item:last-child:hover,
:last-child > .popup-menu-item:last-child:hover
but that's hardly better with its heavy reliance on implementation
details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4940
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2126>
The cursor texture, scale and position is captured separately and
overlaid on top of the preview, and on top of the final screenshot
image. This allows toggling it on and off post-factum.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
UIWindowSelectorLayout is a stripped-down subclass of WorkspaceLayout
(we don't have to deal with windows disappearing or appearing or
changing size). UIWindowSelectorWindow is a heavily stripped-down
version of WindowPreview. UIWindowSelector is analogous to the Workspace
class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
- increase the looking glass outer radii
- adjust the colours to be less dark
- fix oversized notification close icon
- fix separators and reduce padding in popovers
- fix colour mismatch in switch assets
- fix color of no-notifications asset
- rename assets to be consistent with dark-as-default scheme
- update checkbox assets
- fix calendar today border
- reduce icon size of placeholder notifications icon
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2111>
- updated switch assets
- new high contrast assets
- use non-hardcoded bg color for dash
- updated palette colors
- add missing color definitions to hc
- increase radii of many elements
- update search entry style
- align icon better in search entry
- restyle panel popovers without arrow and add drop shadow
- used theme colors in panel
- fix some things with popover labels
- new slider style
- some light variant fixes
- fixes to the calendar popover
- day with event styles
- better calendar-today.svg and dark variant
- shorten calendary weekday header
- saner padding
- overhaul popover menu style
- minor fixes to app grid and alt-tab switch
- updated looking glass styles
- nm-dialog adjustments
- search results adjustments
- expand out panel button hover styles
- button drawing adjustments
- adjust notifications area
- update on-screen keyboard style
- better keyboard symbolic icon assets
- change keyboard symbolic icons to 24px
- improved keyboard style
- gave the keyboard word suggestions some styles
- less obnoxious saner media control buttons
- cleaned up the css for the dash
- reworked the alt-tab switcher style
- sync style on workspace switcher
- adjusted dialog button style drawing
- popover submenu redrawing adjustement
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2104>
Ultimately, we want to add support for GDM's new ChoiceList
PAM extension. That extension allows PAM modules to present
a list of choices to the user. Before we can support that
extension, however, we need to have a list control in the
login-screen/unlock screen. This commit adds that control.
For the most part, it's a copy-and-paste of the gdm userlist,
but with less features. It lacks API specific to the users,
lacks the built in timed login indicator, etc. It does feature
a label heading.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1978>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
It's not visible because it's covered by the actual wallpaper, so
not rendering it eliminates most of the render time for
`workspace-background`, without changing its appearance.
When animating the overview by tapping Super, this reduces the
shell's overall render time by about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
The migration happened in GNOME 3.6 over 9 years ago. The chances
that someone migrates from 3.0.x or 3.2.x to 41 are very much zero.
And if it were to happen, it wouldn't work anyway, because we stopped
using a separate overrides schema.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1890>
org.freedesktop.impl.portal.desktop.gnome will be used for the
GNOME implementation of desktop portals in the future, so make
sure GNOME Shell's implementation of the access portal won't
conflict.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1872>
Now that we made window previews overlap the edges of the wallpaper
underneath them, the app icons of those windows are getting quite close
to the dash and there is almost no more spacing.
Let's make it look a little bit better and slightly increase the
margin-top of the dash so that the workspaces move a few more pixels
away from the dash.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
On the new horizontal workspace-thumbnails, the old placeholder from
vertical dash appeared too small, and was easily hidden behind the
dragged window/icon. Rotate the placeholder 90 degrees to better fill
the spacing between thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1801>
At the moment the timed login feature is implemented in the user list.
If there's no user list, we don't show the indicator anywhere and
don't proceed with timed login.
This commit allows timed login to work when the user list is disabled.
It accomplishes this by putting the timed login indicator on the
auth prompt in that scenario.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1809>
With the introduction of the transparent panel in the overview, we
started making the panel text/icon color slightly brighter in the
overview and on the lockscreen to ensure best contrast. Now
unfortunately, setting the text color incurred a relayout of the
underlying ClutterText actor (fixed with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750), and
setting the icon color causes the icon texture to get regenerated
(fixed with
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932).
Regenerating the icon texture will replace the icon actor, which also
causes a relayout.
This relayout of the panel has been measured to add at least 1
millisecond (the numbers fluctuated a lot) to about 5 ms it takes to
layout the first frame when showing the overview.
Since https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932 is
unlikely to land this cycle, this commit proposes a different solution:
Simply don't use a different color for text in the overview. To avoid
issues with contrast in the overview, make the default color slightly
brighter and change it from #ccc to #ddd.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
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>
This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1695>
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>
The reason this wasn't using the Gio.DBus.makeProxyWrapper() convenience API is that it passes custom flags to the proxy, and that wasn't supported by the wrapper at the time.
As this is now possible, this commit migrates us to the new API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1572>
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.
That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.
Fix this by using a custom name for a custom icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
Adwaita uses ui/ for the corresponding icon, but GTK treats icons
from a resource path as part of the hicolor theme that doesn't
have such a subdir. And as GTK determines subdirs by enumerating
the theme directory, any subdirs that only exist in the resource
are ignored, whoops.
Make sure the icon can be found by moving it to a standard subdir.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
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>
Clarify the comments on ConditionEnvironment= by mentioning that a
ConditionEnvironment= line must be located in the [Unit] section.
The comments suggesting using ConditionEnvironment= themselves are
in the [Service] section, which implicitly and wrongly suggests
that ConditionEnvironment= could be defined right there as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1472>
Screen magnification is the compositor's business, not that of "random"
unprivileged tools. And for cases where a more specialised behavior is
wanted, an extension likely does a better job than a consumer of the
D-Bus API.
In addition to that, exporting the interface has been broken for an
unknown time, because the object that holds the implementation isn't
referenced and thus ends up being garbage collected, whoops.
And last but not least, this gets rid of the last public D-Bus name
that isn't clearly in the system namespace (org.gnome.Shell,
org.gnome.Mutter, org.gtk).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3452
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1523>
Move the GNOME shell service file adapation for x11/wayland into the
target/service files. This means that the session definition can simply
pull in org.gnome.Shell.target, without having to care about whether it
is starting an X11 or wayland session.
Note that this currently requires fork'ing to do the test. This will
however not be needed in the long term when ConditionEnvironment becomes
available (see https://github.com/systemd/systemd/pull/15817).
We technically do not need to use template units. But doing so means
that the unit can be translated to the app id more easily (though it is
not yet completely clear how this should look like in the long term).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
In general we want to move towards using reverse domain names for
systemd units. Doing this also means we have a consistent name between
desktop file and systemd unit, allowing us to create a generator that
pulls in the unit as defined in the sessions RequiredComponents.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Move the screencasting into a separate D-Bus service process, using
PipeWire instead of Clutter API. The service is implemented in
Javascript using the dbusService.js helper, and implements the same API
as was done by screencast.js and the corresponding C code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
This is the key that will be used to store the pages and the icons in
each page. The idea is that we we store an a{sv} variant for each page.
This variant will contain <icon id> → array of properties, where we
can store arbitrary data for each icon. The expected output of this
key is:
[
{
'polari.desktop': <{ 'position': 0 }>,
'epiphany.deskop': <{ 'position': 1 }>,
},
{
'telegram.desktop': <{ 'position': 2 }>,
'builder.desktop': <{ 'position': 0 }>,
'gitg.desktop': <{ 'position': 1 }>,
}
]
The toplevel array is sorted, and pages of the grid always show in the
order they are stored.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
While GtkIconTheme does look up icons in the toplevel icons resource
path, it will only use them as ultimate fallback. That is, if the
icon theme (or the hicolor fallback) include a "keyboard" icon, it
will be used over the "keyboard-enter-symbolic" icon in the resource.
Moving the icons to appropriate subdirectories gives them higher
priority than the fallback names, and thus fixes the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2631
Switch to the new WorkspaceLayout layout manager to allocate the window
clones of the overview properly using Clutters layouting mechanisms.
Since we now no longer make use of the fullGeometry, we can remove the
setFullGeometry() function from the Workspace class. Also we can stop
setting the actualGeometry on the Workspaces and WorkspaceViews and
instead just set the fixed position and size of the views to their
full or actual geometry. This also has the benefit that we no longer
have to set a custom clip, but can simply enable clip_to_allocation.
The geometry needs to be set inside a BEFORE_REDRAW later because
_updateWorkspacesActualGeometry() is called from a notify::allocation
handler.
This isn't doing any animations when showing/hiding the overview yet,
we'll add that in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Using CSS to center the title actor on the border is a bit ugly, because
it requires the CSS to match the calculations used in chromeHeights().
Also it is not possible to use CSS margins for cases where the position
of the actor is determined at run time, such as for the close button.
Instead use an invisible actor that spans between the horizontal and
vertical center lines of the border as guide when aligning the title
actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
Start using the new overlays we introduced in the last commit and remove
the WindowOverlay class and the objects for keeping track of them in the
Workspace.
The new layout which doesn't use the -shell-close-overlap CSS property
anymore sligthly changes the position of the close button to be a bit
further away from the actual window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Events have a clear and obvious connection to the calendar, and similar
to the Clocks and Weather sections there's a strong link to a particular
application.
Adding them as another section to the right-hand side of the calendar
therefore presents a viable alternative to the old events section.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
Being able to visualize the actor tree is a handy feature
to have, specially when debugging the hierarchy.
Add a new "Actors" tab to the Looking Glass with the actor
tree inspector. The tree is cleared on unmap to not get
heavy on the number of actors.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1292
The Frequent apps grid has a few problems:
* On a fresh install there would be no history of app usage so the
applications shown in the grid have no relevance it takes time
to be useful instead of being useful from the start;
* The grid has far too many items in it to be relevant; 24 apps is
well beyond the average use case as most people don't frequently
use that many, so it gets populated with several apps that are
single use (hello xterm);
* The position of items in the grid are always changing based on an
unknown frequency metric (and not by user-intended input) which
makes it a poor way to quickly launch apps as one would have to
constantly learn the positions of the items in the grid;
* Having two app grids is a bit superfluous and needlessly complicates
the app launching navigation: you have to spend time checking the
frequent grid and if it's not there you have to switch over to another
grid and find the app you need in there it's not straightforward.
Remove the Frequent tab and simplify the related code.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1425https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
