Commit Graph

147 Commits

Author SHA1 Message Date
Georges Basile Stavracas Neto
c4e43efb1e overview: Implement startup animation
The new startup animation consists of rising the Dash from the bottom,
falling the search entry from the ceiling, and going from HIDDEN to
WINDOW_PICKER with an opacity applied.

One little trick from IconGridLayout was added to ControlsManagerLayout,
which is a promises-based wait for allocation. This is required to make
sure that the transformed position of the search entry is valid, which
is only the case right after an allocation.

This animation also ensures that the overview is shown right on startup.

For session modes that do not have an overview, continue using the same
fade + scale animation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Georges Basile Stavracas Neto
930d0b6151 overviewControl: Store search entry container
It'll be used by the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Florian Müllner
2731d35723 workspaceThumbnails: Pass monitor index to constructor
We'll soon add workspace thumbnails on secondary monitors as well,
so set the monitor explicitly instead of assuming the primary one.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
f28f7eddb1 overviewControls: Shift up on double-super
Right now a second super press during the overview transition hides
the overview again. Change that behavior to shift up to the app grid
instead, which is more useful.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1736>
2021-03-02 15:36:26 +01:00
Florian Müllner
1ad45a8232 overviewControls: Handle overlay key
It's where all the fun state is handled now, so move the super-key
handling there as well, in preparation of making it a bit more
sophisticated.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1736>
2021-03-02 15:36:26 +01:00
Alexander Mikhaylenko
8eda12e6d7 overviewControls: Use easeOutCubic transition for overview
Swipe tracker duration is intended to be used with easeOutCubic only.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1732>
2021-02-28 19:57:53 +05:00
Florian Müllner
e0c0662164 overviewControls: Remove superfluous max()
We don't need to call Math.max() to figure out the maximum of a
single value :-)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1709>
2021-02-22 13:10:02 +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
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
Carlos Garnacho
cd506d45ef overview: Make 3fg vertical swipes bring overview and app grid
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>
2021-02-17 14:06:11 +01:00
Carlos Garnacho
ddb8782179 overviewControls: Add "gesture-in-progress" property on the state adjustment
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>
2021-02-17 14:06:11 +01:00
Georges Basile Stavracas Neto
c0a4d90847 overviewControls: Limit Dash height to 15% of the overview's
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>
2021-02-11 22:31:50 +00:00
Georges Basile Stavracas Neto
c8f1dca3c7 Rename ViewSelector to SearchController
Rename ViewSelector to SearchController, since ViewSelector now effectively
only handles search. Rename the file correspondingly as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
2021-02-11 21:14:36 +00:00
Georges Basile Stavracas Neto
27627bd40a viewSelector: Cleanup pages
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>
2021-02-11 21:14:36 +00:00
Georges Basile Stavracas Neto
bf1fa3879f workspacesView: Interpolate against relative workspace boxes
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
9c6d8e2aad overviewControls: Cache workspaces boxes
Next commit will need to access the allocated workspaces boxes, so
cache them at allocation time.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
87645652e5 overviewControls: Make AppDisplay rise from the bottom
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
c09c070b15 overviewControls: Incorporate ActivitiesContainer
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
83127bf805 overviewControls: Use specialized class for Overview adjustment
It'll be useful for the next commits to have a handy 'getState' method
that calculates the progress of any particular transition.

Move the St.Adjustment to a specialized subclass.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
80d258b20f viewSelector: Move 'toggle-applications-view' to ControlsManager
Move the shortcut handling into ControlsManager, and reimplement
the callback in such a way that it behaves correctly with the
current overview machinery.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
b32f414919 viewSelector: Remove showApps()
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
8089d7cbf7 overivew: Propagate target state when animating to overview
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
22f4a6b7f6 workspace, workspacesView: Cleanup animation methods
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
1ad1db406e overview: Don't fade OverviewActor
Now that the workspace display is properly allocated for each frame,
we don't want to fade the entire overview anymore.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
b6337a7bf1 overviewControls: Ease main adjustment when animating to/from overview
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
0a8aeebd30 overview: Reorganize animateTo/FromOverview()
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
e6e5a93dec viewSelector: Use state adjustment for apps page
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
3887253823 overviewControls: Use adjustment to control layout
Right now, the adjustment is fixed at ControlsState.WINDOW_PICKER,
but soon it will be propagated to ViewSelector to control the
transitions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
55510e9cdf overviewControls/controlsManager: Use a custom layout manager
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>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
301686ee5f overview: Move search entry to ControlsManager
Next commit will tie all these widgets up with a single
layout manager, and we need to control the search entry
position.

Move it to OverviewControls.ControlsManager.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Florian Müllner
73b94c3901 overviewControls: Remove DashFader
By now there is so little left of the old sliding controls that the
split from the actual dash makes little sense.

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/89

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1660>
2021-02-10 15:46:00 +00:00
Florian Müllner
ac3faac38c overviewControls: Remove intermediate box
Now that the workspace switcher moved into the view selector, the
box only holds a single child. Cut out the middle man and add that
directly to the parent.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1609>
2021-01-29 17:49:52 +01:00
Georges Basile Stavracas Neto
99d1529e8c overviewControls: Simplify DashFader
Merge FaderControl and DashFader, since it's the only subclass, and
remove all overview connections that aren't useful for it.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
f17d9676f8 overviewControls: Move workspaces thumbnails to ViewSelector
This is now all centralized in the apps page, so move the workspaces
thumbnails to ViewSelector's apps page. This allows us to remove
all the slider controls too, since they're now unused.

The transition between showing the workspaces, and the app grid, is
based on the most recent mockups: scale and move it down, and fade it
out.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
de15eb3bbc viewSelector: Merge WINDOWS and APPS pages
Add them both in a StBoxLayout subclass with a vertical layout. This
new ActivitiesContainer class already contains an adjustment controlling
the transition between workspaces and app grid states, and althought it
is internal to it, it'll be easy to integrate with gestures in the
future.

Notice that AppDisplay is added before WorkspacesDisplay. That's because
we want the paint order to paint WorkspacesDisplay on top of AppDisplay.

Switch the ViewsPage enum to call this page ACTIVITIES, and adjust the
only caller in OverviewControls to it. At last, rename '_appsPage' to
'_activitiesPage' to also reflect the name change.

The usefulness of organizing this code in pages is lost here, but this
is a transitional state, and pages will be removed in future changes.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Florian Müllner
a5730d7b30 overviewControls: Make sure dash is positioned at the bottom
We don't want the dash to expand, but if it's given more space
than requested, we want it to be positioned at the bottom.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1577>
2021-01-20 11:34:43 +00:00
Florian Müllner
b3c13d6128 overviewControls: Simplify dash placement
Now that the dash is always visible, it doesn't make sense to keep
it in a separate layer from the main overview group and use a
separate spacer actor as a placeholder.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1575>
2021-01-19 15:06:58 +01:00
Georges Basile Stavracas Neto
97eb4560ef Make Dash horizontal
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>
2021-01-19 13:47:06 +00:00
Georges Basile Stavracas Neto
bd850c3110 overviewControls: Split FaderControl from SlidingControl
The Dash will need only the fading aspect of SlidingControl in the
next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
2021-01-19 13:47:06 +00:00
Georges Basile Stavracas Neto
ea02aa399d overviewControls: Show DashSpacer in apps page as well
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
2021-01-19 13:47:06 +00:00
Georges Basile Stavracas Neto
c9a6424f2e overviewControls: Simplify DashSpacer
Make it subclass ClutterActor, since we don't need any of StWidget's
features. Pass the source actor of the bind constraint in the
constructor, and remove the extra method to set the source actor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
2020-12-02 22:43:04 +00:00
Georges Basile Stavracas Neto
491a69a5a2 overviewControls: Remove ControlsLayout
ControlsLayout is a tiny layout manager whose only purpose
is emit "allocation-changed" after allocation. This signal
was listened to update the workspaces actual geometry.

However, since d66cd0d206, ControlsManager doesn't listen
to this signal anymore, rendering the class useless.

Remove ControlsLayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
2020-12-02 22:43:04 +00:00
Björn Daase
2fc6384bca *: Fix spelling mistakes found by codespell
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1416
2020-08-21 18:25:09 +00:00
Florian Müllner
d66cd0d206 workspacesView: Don't set full geometry
It's not used anymore.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
2020-07-07 00:06:53 +02:00
Jonas Ådahl
5ea54426b9 st/adjustment: Add ::actor property
Will be used by transitions to set the timeline actor.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1299
2020-07-02 20:50:03 +00:00
Daniel van Vugt
c7e597cf72 overviewControls: Animate sidebars the same duration as windows
When you tap Super and see the sidebars and windows slide, it looks more
cohesive if those animations complete at the same time.

Previously there were 0.09 seconds difference between the two animations
which was enough to make it look slightly buggy. Now it doesn't.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1289
2020-06-23 19:07:30 +00:00
Jonas Dreßler
9b99b67fea Remove ClutterAllocationFlags
Those flags were removed from Clutter since they're pretty much unused,
so remove them here, too.

See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1245
2020-05-20 15:12:03 +02:00
Florian Müllner
2e80995f19 overviewControls: Remove transitions before updating adjustment value
The workspace switcher blocks state updates while the indicator is
animating. Since commit 9c1940ef9d the indicator is considered to
be animating when the workspace adjustment's value doesn't equal the
active workspace.

There is one case though where this breaks badly: When a workspace
is inserted before the active one, the adjustment's upper and value
properties are changed without transitions. But if that change happens
while there's an ongoing transition to the previously active workspace,
the value gets out of sync with the active workspace and we end up
blocking state updates indefinitely.

Fix this by removing any transitions before setting the adjustment
value.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2625
2020-04-28 01:28:50 +02:00
Florian Müllner
9d941f8202 js: Don't use templates in files with translations
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.

Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
2020-02-17 23:20:40 +01:00