This reverts commit e31693bbee.
This doesn't properly adjust the allocation, leading to an unbalanced
overview where things aren't centered properly. Just revert for now,
and we'll rethink this next cycle.
When coming back from search or apps, the workspace thumbnails and dash
don't slide in but "pop in". This is because of bad timing: when slideIn
is called, we immediately start the translation animation, and it
completes before by the time we fade the new page in.
Fix this by calling slideIn and slideOut at two different times: we now
slide out when the old page with our controls is fading out, and slide in
when the new page with our controls is fading in.
https://bugzilla.gnome.org/show_bug.cgi?id=708340
We currently update workspaces geometry when we are notified about
allocation changes of the overview group; however as the geometry
is based on stage coordinates, we miss notifications when the
allocation relative to the parent is unchanged, which happens when
the primary monitor's position changes but not its resolution.
Use a custom layout manager to give us a signal that is emitted
reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=708009
The main overview actor was made reactive to catch scroll-events
and propagate them; after some code shuffling, the actor that
catches scroll events ended up not being the same actor that's
supposed to propagate this, which broke using the scroll wheel
to switch workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700595
As we want to eventually track two geometries, we need to rename
our very plain "_x, _y, _width, _height". While we could just prefix
them, I think that stuffing them in an object makes more sense.
At the same time, make the variable and method name more descriptive
by adding such a prefix, as well as a bit of documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
To ensure that we don't recalculate window layouts when zooming
in or out, we need to always pass the full geometry. This will
break window repositioning when we zoom back in; for the purposes
of commit clarity, this breaks this feature for now. It will be
added back soon.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
Instead of creating a bunch of random actors and then passing
them off to the controls manager, let the controls manager
construct them. This leaves the controls manager in charge
of the ordeal.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
We always leave the workspace switcher zoomed out when we can assume
that the user is actually making use of workspaces. For the default
dynamic workspace behavior, we make this assumption when more than
two workspaces are in use (e.g. at least two workspaces contain windows
plus an empty one at the end). However this test does not make sense
when using static workspaces - in that case, not using workspaces
would be indicated by a workspace number of 1 (in which case the
entire switcher is hidden completely), so add a check for dynamic
workspaces to the condition.
https://bugzilla.gnome.org/show_bug.cgi?id=695126
We generally want view content centered, in particular where the
view itself is symmetrical. So move the dash to a separate layer
and use a placeholder to account for its size when showing the
window picker, which is the only view where it doesn't make sense
to center the content.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
All the complexity with a custom actor and a generic container was
just to add some padding below the overview controls. Remove that,
and use CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694100
If the animation time is not the same for these two, the translation
will be adjusted to the allocation during the tween, resulting in a jump
in the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=694035
Account for the search entry space at the bottom (the former message
tray clone) individually in each side control, instead of packing
another actor in the overview.
This allows us to extend the central view all the way to the bottom,
while still keeping controls centered vertically.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
And use it in overviewControls. When we moved this code from overview.js
to overviewControls.js we lost a condition so we now slide in controls
even when going back from the overview, which looks bad.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
The slideX property controls the allocation of the view selector; since
we now know when there are no visible views from the page-empty signal,
we can use it to set the full slideX for the next page at that time,
allowing the new view to fade in with the right width.
This allows us to use simple x translations for the side components when
switching pages, keeping the noise due to resizes at the minimum.
The slideX resize for now is kept for DnD, and will always be needed for
the thumbnails box when showing the windows page.
https://bugzilla.gnome.org/show_bug.cgi?id=693924
SlideLayout is a fixed layout that takes care of requesting and
allocating the right sizes so its contents can slide horizontally as the
actor is resized.
Sliding is controlled with a slideX and slideDirection properties, which
do the right thing wrt. RTL automatically.
Also add a SlidingControl base class that will be used by the overview
to pack and slide the workspace thumbnail switcher and the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=682050
