Since commit 9980c80619, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).
To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.
The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3781
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1721>
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.
To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1707>
Since commit 0f1b566918, we use gjs' automatic getters/setters for
the shader properties. Those handle the properties on the JS and
GObject side, but they don't update the corresponding uniform,
whoops.
Revert the lightbox bits of commit 0f1b566918 to get the effect back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1712>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.
This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.
The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.
Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.
But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).
Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touch swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the touch events and look if it matches
the expected orientation before accepting the gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Make the touchpad gesture keep track of its state, and enter in a
rejected state if the swipe is happening in the wrong direction.
Effectively, this means touchpad gestures are locked on a single
direction, and horizontal+vertical swipeTrackers won't be handling
events at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touchpad swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the swipe events and look if it matches
the expected orientation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
Even if activePage has been removed as part of commit 27627bd40, we've
still a reference of it in key press handler.
Given that there's no anymore an active page to redirect input to,
remove these references, so that can be handled in the proper view to
implement key-navigation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1688>
When opening a large number of windows, the computed space and scale for
a layout can become negative due to the per-row/per-column spacing. This
is smaller than the initial values of lastSpace and lastSpace, leading
to a null return which then causes all sorts of other issues resulting
in the workspace becoming invisible.
This change ensures that the function always returns a layout, even if
it may look a bit broken and does not conform to the scale/space
requirements which are impossible to fulfill for the given number of
windows. It's better than displaying nothing, since it allows users to
move/close windows and restore this to a more usable state.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3730
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1685>
When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>
Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.
The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
Scaling the icons all the way from/to 0 is a relatively big transition,
which is fairly distracting when playing simultaneously for multiple
previews after reaching the WINDOW_PICKER state.
Instead, tie the scale to the overview state itself, so that the animations
runs in parallel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1654>
Back when the Dash was vertical, the size of each item was calculated
solely based on the available height. After making the Dash horizontal,
this was swapped by the available width. However, when the height of the
Dash decreases, the current code results in never scaling them up ever
again.
Fix that by making ControlsManagerLayout explicitly pass the maximum Dash
sizes. Remove the 'notify::width' handler that served the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1638>
Remove the dummy applications page that was introduced as a temporary
step. Replace the 'page-changed' and 'page-empty' signals with a 'search-active'
boolean property.
Remove ViewSelector.ViewsPage since it's now unused, and all the page handling
mechanism. At last, since we don't use any ShellStack features anymore, simply
make it a St.Widget with a ClutterBinLayout as the layout manager.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
In addition to disabling the overlay when the state is not 1,
disable it also when not in the active workspace.
Make the Workspace class track the workspace's active state,
and resync the overlays when it changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The behavior of workspaces is different depending on whether
the overview is in window picker state, or app grid state.
When in window picker state, clicking on adjacent workspaces
should only activate them, without hiding the overview; and
clicking on the active workspace hides the overview. When in
app grid state, clicking on a workspace must always hide the
overview.
Pass the overview adjustment to Workspace, and leave overview
if the overview state is bigger than WINDOW_PICKER.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The overview transition consists of getting the initial and final
states of the overview adjustment, derivating various other internal
states from them (such as the fit mode, opacities, translations, etc),
and finally interpolating the allocation boxes.
When interpolating between the fit mode, WorkspacesView uses the current
allocation box to derivate the SINGLE and ALL fit mode boxes. However,
that creates a curved path during overview transitions. What we really
want to do here is calculate the fit mode box relative to the corresponding
overview state. For example:
+----------------+----------+------------------------+
| Overview State | Fit Mode | Workspaces geometry |
+----------------+----------+------------------------+
| HIDDEN | SINGLE | Cover entire screen |
| WINDOW PICKER | SINGLE | Between minimap & Dash |
| APP GRID | ALL | 15% screen height |
+----------------+----------+------------------------+
Using the table above as the reference, when the overview transitions
between WINDOW PICKER and APP GRID, we must interpolate between
(SINGLE fit mode @ between minimap & Dash) and (ALL fit mode @ 15% screen
height). That way, we always interpolate the final boxes, which corrects
the odd path that workspaces follow during this transition.
Make the WorkspacesView of the primary monitor use these cached boxes
when the overview is in the middle of a transition, and the fit modes of
the initial and final state differ, to calculate the workspaces positions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
It makes more sense in a spatial overview that the app grid
comes and goes to somewhere in the screen, instead of fading
in and out into the void.
Make the app grid rise from the bottom of the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Move AppDisplay, WorkspacesDisplay, and ThumbnailsBox from ViewSelector to
ControlsManager. This allows to always allocate the correct size for AppDisplay,
and will enable for a plethora of further improvements. The end goal is to
completely remove ViewSelector, and let ControlsManager handle the layout of
everything that's visible in the overview.
For now, replace the apps page with a dummy actor in ViewSelector.
Adjust various callers around the codebase to not access the ViewSelector
directly from the overview anymore.
Bind the opacity of the primary workspace to WorkspaceDisplay's opacity. This
allows removing the parent opacity hack in place, which will be done by the
next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Now that Overview is able to ease into any state, be it window
picker or app grid, we can move this ViewSelector method to
Overview itself, which is its rightful place to live.
Remove ViewSelector.showApps(), and make all callers call
Main.overview.show(ControlsState.APP_GRID). Also make sure the
show apps button is correctly toggled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Next commits will requires ControlsManager to animate to different
states, depending on how Overview is called. Add a new 'state'
parameter to ControlsManager's, and OverviewActor's animateToOverview,
and Overview.show().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Remove Workspace.zoomTo/FromOverview(), they're unused now. Rename
everything up to ControlsManager to prepareToEnter/LeaveOverview(),
since these classes don't run the animation anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
WorkspacesView uses the floating layout when the overview is in window
picker mode, and the session layout when the overview is in app grid
mode. Up until now, the fit mode adjustment was used to derive the
workspace mode, but it is incomplete as it doesn't have the full range
of workspace states.
Make ViewSelector cascade the overview adjustment to WorkspacesDisplay,
and use the overview adjustment itself to derive the workspace mode.
Extra workspaces don't have to account for the fit mode, and thus are
basically a clamp(state, 0, 1) of the overview state. However, don't
call animateTo/FromOverview() anymore, since they ease the workspace
mode adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Boy, does this commit feel good.
While the workspaces view on the primary monitor *appears* as part of
the overall overview hierarchy, this hasn't actually been the case
until now. We synchronized its size and (stage) position to match
the workspaces display, but actually kept in a separate layer for
the transitions to and from the overview.
But now that the new layout manager slides out completely during the
overview transitions, the workspaces display starts out covering the
entire work area, which is exactly what we need for the transition.
So finally stop faking it, and actually make the primary workspaces
view a child of the workspaces display.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of delegating it to ViewSelector, make the transition to and from
overview ease the main state adjustment.
This commit temporarily breaks these animations, but on the other hand
introduces an important feature: ViewSelector is always allocated to the
actual size. This will finally allow for adding WorkspacesView as a child
of WorkspacesDisplay, and finally remove the actual geometry hack, which
is what next commit is about.
This commit also effectively reverts b64103efc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of directly accessing ViewSelector and calling these methods
there, cascade the calls to OverviewActor, ControlsManager, and finally
ViewSelector. Also move the opacity transition to OverviewActor.
This commit has no functional change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, ActivitiesContainer reacts to showAppsButton and
transitions between app grid and window picking states on
its own. In the future, we want full control over this.
ControlsManager already has a state adjustment that represents
all possible overview states. Propagate this adjustment up to
ActivitiesContainer, and use it to drive the transition.
This requires moving the callback to the showAppsButton to
ControlsManager, since now it control the state adjustment
itself, not ActivitiesContainer's adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
