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
With color picking implemented in the compositor, we
can do better than letting the user pick a pixel with
the crosshair cursor, and present them with a preview
of the color that will be selected.
Do this by replacing the cursor with a custom icon and
apply a recoloring effect, where we replace a given color
with the color of the currently hovered pixel (similar
to a green screen).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/451
Replace the usage of IconGrid in the grid search results by
a custom layout manager that only allocates as many children
as the actor can fit.
This new layout manager does not implement changing the icon
size depending on the screen size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1265
Now that the extension preference dialog is opened by a separate
D-Bus service rather than the Extensions app, it can be opened
without a parent window that provides name and icon.
Fix this by adding back a hidden .desktop file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2562
We had various requests to improve existing OSK layouts, but
haven't accepted them so far as any changes would be overridden
when regenerating the layouts.
However as the upstream layouts at http://www.unicode.org are
extremely slow to update(*), we shouldn't block all improvements.
So instead of letting the update script override all existing
layouts, just make it import new layouts.
(*) not their fault, as the android layouts are a downstream to Google
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
The module was imported into the toplevel in !424, but that's at
least a bit weird:
- it's a helper script for one particular aspect (OSK layouts)
- it adds a README.mdwn to our own README.md, and a test/ directory
to our tests/
Move the whole thing to a subdirectory under data/, which is more
appropriate.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1136
Use a brighter color and increase the contrast of the selected/active
items in the switcher popup.
Since a bright color doesn't go well with a box-shadow, remove that
shadow, an effect like should only be used for elements clicked with a
mouse anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1135
When mutter is acting as a display server it sets a number of
environment variables in the user's session. These variables
tell applications where the display server's sockets are.
When the shell exits at logout time it leaves these environment
variables in the systemd --user environment, which can confuse
subsequent sessions.
This commit clears up the environment on exit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1129
Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
Commit 6c6c89c634 added a pill around the default avatar, but
assumed the sizes from the vertical widget used on the lock screen.
In order to fix the horizontal widget on the login screen, move the
size-specific bits to the corresponding .horizontal and .vertical
sections, and half the sizes for the former (which corelates with
the icon sizes).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2242
