Commit Graph

15761 Commits

Author SHA1 Message Date
Aurimas Černius
ea5efbbd52 Updated Lithuanian translation 2021-02-21 21:22:13 +02:00
Jonas Dreßler
63a96a7111 workspacesView: Take scale factor into account to calculate spacing
This is a statically defined size and we need to adjust for scaleFactor
ourselves, so do that and multiply those two values by the scale factor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1701>
2021-02-21 16:25:17 +00:00
Jonas Dreßler
2d954c07fb workspace: Don't limit workspaceBox size when doing app grid animation
In the allocate() vfunc of WorkspaceLayout we use a small trick to make
the nonlinear animation paths when opening the overview less jarring:
Because a window might get smaller than its target size during the
animation, we make sure the size never drops below the final size
calculated by the layout strategy.

In the app grid the Workspace is very small though, and the size of a
window slot calculated by the layout strategy might actually be larger
than the workspaceBox. This means we might use the window slot size
instead of the workspaceBox size and end up with a window that's at the
correct position, but its size is too large.

Fix this by only applying this trick when we're animating towards or
from the state where we actually expect the workspaceBox to be larger
than the window slot, that is during the the transition from the session
to the window picker (or the other way round).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
2021-02-21 17:03:09 +01:00
Jonas Dreßler
9e8ceeae9d workspace: Actually apply top overlap to the top
The top overlap is accidentally being applied to the left edge right
now, fix that and apply it correctly to the top edge.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
2021-02-21 17:01:07 +01:00
Jonas Dreßler
51348c6020 workspace: Properly handle zero spacing in the WorkspaceLayout
It should be allowed to set this._spacing to 0 and thus pass 0 as
rowSpacing or colSpacing to this._adjustSpacingAndPadding(). The current
if-condition there won't add the oversize to the spacing in case 0 is
passed though.

So change that if-condition and explicitely check for null instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
2021-02-21 17:01:07 +01:00
Georges Basile Stavracas Neto
adc5f2d81f workspace: Scale down background
Scale down the background to 0.94 when in floating mode.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
b1970b95b8 workspace: Clip window previews
Window previews can spill out of the container when their position in the
session overflows the monitor boundaries. In the past, Workspace didn't have
a visible background, and was (almost) always fullscreen, which would mask
this particular problem. However, nowadays, it is very much noticeable when
this situation happens.

Clip the window previews container to its allocation when the overview state
is bigger than WINDOW_PICKER. That is, between HIDDEN and WINDOW_PICKER states,
inclusive, no clipping is applied.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
1819e34f29 workspace: Move border radius handling to WorkspaceBackground
Let WorkspaceBackground itself manage its background radius.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
a17c4283ea workspace: Add WorkspaceBackground to Workspace itself
Instead of adding it to the window previews container, add it to Workspace
itself. This requires expanding WorkspaceBackground, so add the relevant
x and y expand flags.

Since the background is beneath the window previews, create and add it before
the window preview container.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
37bcd3d428 workspace: Move window previews to a child container
Currently, Workspace is a single actor that contains both the background,
and all window previews, and is managed by WorkspaceLayout. In the future,
this concentrating aspect of it will bite us; we want the window previews
to be clipped to the allocation, but not the background, since it will
have shadows.

Make Workspace subclass St.Widget with a ClutterBinLayout as layout manager,
and move window previews to a child actor. To reduce the impact of this
extra actor, it's a ClutterActor instead of a StWidget, and the spacing is
still set on Workspace itself.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
b05280a2cd workspace: Update background on workarea changes
The WorkspaceBackground class has specific code to clip the background
to the workarea. However, it doesn't monitor for workarea changes, which
means it cannot react after being created.

Connect to 'workareas-changed', and update the workarea, the radius bounds,
and relayout when workareas change.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Georges Basile Stavracas Neto
9d4f017248 workspacesView: Only clip non-primary workspace views
The primary workspace is displayed in the overview, and clipping it
ends up clipping the shadows too. Since Overview's ControlsManager
itself clips to allocation, no windows in the primary monitor spill
to other monitors. However, not clipping non-primary monitors might
end up in situations where their windows spill into the primary one.

Make sure to only clip workspace views of non-primary monitors.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
2021-02-21 15:47:12 +00:00
Jiri Grönroos
a976fe90e4 Update Finnish translation 2021-02-21 13:41:18 +00:00
Kukuh Syafaat
52c21c32d5 Update Indonesian translation 2021-02-21 13:22:01 +00:00
Daniel Șerbănescu
3c126f4422 Update Romanian translation 2021-02-21 11:30:45 +00:00
Evan Welsh
9a50240bbc schema: Enable extension version validation by default
Previously this was disabled to avoid requiring extensions to manually
update on each release. For 40 this behavior will likely be too unstable
for most users.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1706>
2021-02-20 12:25:00 -08:00
Emin Tufan Çetin
fcb70ff654 Update Turkish translation 2021-02-19 22:12:55 +00:00
Anders Jonsson
0ede01e676 Update Swedish translation 2021-02-19 22:08:24 +00:00
Enrico Nicoletto
3208cc68f6 Update Brazilian Portuguese translation 2021-02-19 21:10:35 +00:00
Hugo Carvalho
f55196e7fb Update Portuguese translation 2021-02-19 20:55:11 +00:00
Jordi Mas
433ba92c43 Update Catalan translation 2021-02-19 20:21:59 +01:00
Florian Müllner
55e08a3a2f welcomeDialog: Hide overview when taking tour
The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1699>
2021-02-19 17:18:50 +01:00
Jonas Dreßler
bc034d5553 windowPreview: Add scaled extra size to chromeWidths() and chromeHeights
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().

Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Jonas Dreßler
7d40930cd6 windowPreview: Scale up by the same extra size for every window
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.

So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Jonas Dreßler
3795ccbcf3 windowPreview: Use a proper spacing between icon and title
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).

So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.

Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Florian Müllner
ece5220b42 windowManager: Keep a minimum number of workspaces
The scaled down workspace in the window picker looks lonely when there's
no adjacent workspace peeking in. Avoid that by always keeping a minimum
of two workspaces.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
2fdee8e444 workspaceThumbnails: Only show for more than two workspaces
As adjacent workspaces now peek into the window picker, the first
two workspaces are already accessible without the minimap. Hide
it in that case to give more space to the window picker, and to
not clutter the overview for users who aren't using workspaces.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
d3a1557864 workspaceThumbnail: Do not update scale while collapsing
The scale property tracks the relative size at which we display thumbnails
given the space we have available.

That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.

Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
7b1b04f95a workspaceThumbnails: Delay workspace removal while collapsing
Animating a thumbnail removal while also collapsing the minimap
itself doesn't look good, so keep the stale thumbnail until the
minimap is hidden.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
a2751a1b26 workspaceThumbnails: Don't animate thumbnail additions while hidden
This is not just an obvious mini-optimization, it also ensures that we
don't start showing the minimap with an ongoing thumbnail transition.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:05 +01:00
Florian Müllner
a73bea02e8 workspaceThumbnails: Animate showing/hiding
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.

However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.

Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:13:02 +01:00
Florian Müllner
f239179682 workspaceThumnails: Add :should-show property
We currently have two components that show or hide the minimap:

 - the thumbnails hide themselves in case of a single static workspace
 - overview controls show the minimap when no search is active

That obviously doesn't work correctly.

To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Florian Müllner
bf8e762178 workspaceThumbnail: Base n-workspaces on number of thumbs
It's what we base our size request on, and what we actually allocate.
The difference usually doesn't matter right now, but will soon when
we animate the minimap itself.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Florian Müllner
2e9715c97e workspaceThumbnails: Actually use vscale parameter
We pass two scales to setScale(), but only use the first one for
both horizontal and vertical scaling. We'll soon have a use case
for using a different scale for each dimension, so start using
both parameters.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
2021-02-19 01:08:48 +01:00
Jonas Dreßler
267c5f84a8 theme/window-picker: Fixup box-shadow of overview workspace backgrounds
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>
2021-02-18 22:10:02 +01:00
Jonas Dreßler
135c9194cd theme/window-picker: Add box-shadow to the workspace background
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>
2021-02-18 20:59:30 +00:00
Jonas Dreßler
63cf60b731 workspace: Round the corners of the wallpaper
As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.

To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.

Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
2021-02-18 20:59:30 +00:00
Yuri Chornoivan
4ba48b02e8 Update Ukrainian translation 2021-02-18 20:27:11 +00:00
Matej Urbančič
494db57d8c Update Slovenian translation 2021-02-18 20:24:21 +00:00
Florian Müllner
f4b88aac04 overviewControls: Add shortcut for shifting through overview
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>
2021-02-18 19:55:31 +00:00
Georges Basile Stavracas Neto
ac6337848f workspacesView: Disable mouse drag to switch workspaces
During the user research, it was found that users would instinctively
drag the workspace horizontally but would often, in the process,
accidentally drag a window.

Disable dragging workspaces using the cursor for now.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3742
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1694>
2021-02-18 09:43:02 -03:00
Rafael Fontenelle
718a87554f Update Brazilian Portuguese translation 2021-02-18 01:31:36 +00:00
Florian Müllner
c769a2f6f0 dash: Put the dot back into its box
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>
2021-02-17 22:09:22 +01:00
Matej Urbančič
bf15ad7f69 Update Slovenian translation 2021-02-17 18:54:50 +00:00
Carlos Garnacho
0b16565e70 keyboard: Handle edge drag gesture cancellation
Hide the keyboard again if the gesture happens to stay/return
within it's activation threshold.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
c62177e669 keyboard: Make OSK follow gesture progress
With all other gestures offering live feedback of progress, seems
to make sense to update the "swipe from bottom edge to show OSK"
gesture as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
8526776b4a keyboard: Use translation-y property for focus window animations
Just the intermediate state, we still need to synchronize visual and
real window position after the animation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
3346e9923b keyboard: Move monitor management to KeyboardController
Instead of setting it deep down, manage it at the higher level.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
0a12405e01 keyboard: Simplify focus window tracking
Keep the focus window in a single field, and optionally animate
depending on keyboard visibility.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
a6a4e0a504 edgeDragAction: Add signal to notify about progress
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00