Commit Graph

154 Commits

Author SHA1 Message Date
Sebastian Keller
77023135ac overviewControls: Stop transitions when starting a gesture
When starting a gesture to open the overview while a transition to hide
the overview is running, Overview._shown will be first set to false when
starting the transition and then to true by the gesture before the
`onComplete` callback is called. The `onComplete` callback in this case
is `Overview._hideDone()` which starts a transition to show the overview
again which also emits the `showing` signal. Since the gesture emits a
`showing` signal as well, this results in two consecutive `showing`
signals without a `hiding` signal in between.

This breaks the `searchControler` which adds a key press handler to
start the search on `showing` and removes it on `hiding`. So every time
this happens a new handler that will never be removed is added,
resulting in the first key press being repeated.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4004
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
2021-04-29 17:58:45 +00:00
Florian Müllner
28723ac088 overviewControls: Support double-super when animations are off
When super is pressed again during the overview transition, we shift
up to the app grid. That means that the feature currently doesn't
work when animations are disabled (like in a VM), because there is
no transition in that case.

Address this by adding a time-based fallback in that case, i.e.
shift up when a second super-press occurs within 250ms after the
first one.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1811>
2021-04-19 20:24:54 +00:00
Jonas Ådahl
1f0ef7fb46 workspaceThumbnail: Update monitor index on 'monitors-changed'
For the primary monitor workspace thumbnail, we must keep the monitor
index in sync with what is currently the primary monitor index,
otherwise we might end up trying to move windows to non-existing
monitors.

For example, if the primary monitor index was 1 when the thumbnail box
was created, but later, the primary monitor index changed to 0, with the
other monitor being turned off, moving a window to one of the workspaces
on the workspace thumbnail, gnome-shell would attempt to move it to the
monitor with the index the primary monitor had in the past, with the
problem being that that monitor no longer exists.

Fix this by listening on the 'monitors-changed' signal on the layout
manager, and update the monitor index of the primary workspace
thumbnails box. Make sure to connect to the signal before creating the
thumbnails box, as the thumbnails box itself will listen to the signal
and recreate its actual thumbnails, and it must do this with the up to
date monitor index.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1810>
2021-04-14 15:43:09 +00:00
Georges Basile Stavracas Neto
eb96288738 overviewControls: Use correct state when updating AppDisplay visibility
When OverviewControls goes from HIDDEN to APP_GRID, it constantly checks
if AppDisplay needs to be visible or not by checking the current overview
state is bigger than WINDOW_PICKER. Turns out in this case this check is
problematic, because when the current state trespasses WINDOW_PICKER, the
layout manager will have already positioned AppDisplay halfway to its final
position.

Use either the final or the current state, whichever is biggest, when updating
the AppDisplay visibility. It optionally allows passing the overview state
params to _updateAppDisplayVisibility() so that we avoid a few trampolines to
recaltulate the adjustment state.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1805>
2021-04-12 12:06:30 -03:00
Jonas Dreßler
d49606bbaa overview: Get rid of panel ghost actor
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.

We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.

This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
ae23ad372d overviewControls: Return zero preferred size
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.

Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
c239cd398d overviewControls: Hide the appDisplay when it's not shown
Hiding actors allows excluding them from layout, so by hidding the
appDisplay in all the cases where the overviewAdjustment is not actually
showing it, we can save a lot of time on the first frame of painting
the overview because we no longer have to layout the whole appGrid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
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