Commit Graph

416 Commits

Author SHA1 Message Date
Florian Müllner
88244222fd workspace: Use new helper function when accepting drops
Moving a window from a secondary monitor to a non-active workspace
currently fails for the aforementioned reasons.

Use the newly added helper function to address this.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2259>
2022-03-31 17:56:49 +02:00
Jonas Dreßler
b17f00cfb1 workspace: Force creating new layout when there's no allocation yet
Commit ba23279f1f was aimed at fixing a
bug where the layout is frozen so early that we don't have an existing
one to re-use, because no allocation cycle happened yet. It tried to fix
that by forcing the creation of a layout when needsLayout === true,
this turned out to be a bit too much, as it also forced creating a new
layout when the layout was frozen after closing a window (which would
set needsLayout to true).

To fix this regression and still avoid reintroducing the bug the
previous commit fixed, tighten the check a bit and only force creating
the new layout when there's no allocation yet. This makes freezing the
layout after closing a window work again.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2236>
2022-03-13 00:16:19 +00:00
Sebastian Keller
6d3df381b3 workspace: Scale slots to current workspace size when layout is frozen
The transition from the overview freezes the workspace layout at the
start of the animation, which means that the calculated window slots
remain the same while the workspace itslef grows. This causes the
windows to appear slightly shrunk in comparison to the workspace and
shifted to the top left. This is especially noticeable during the
beginning of the animation when there is more weight on the slots than
the original window position and if there are not that many open
windows.

Unfreezing the layout for this transition is not possible, because it
would cause issues with newly opened windows abruptly changing the
layout when the animation happens after starting a new app.

This change instead tries to scale the frozen layout to the current
workspace size. While this is not entirely correct, because this scales
the spacing between the slots as well, it is still more accurate than
the completely unscaled slots.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4616
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1980>
2022-03-06 00:16:50 +00:00
Jonas Dreßler
ba23279f1f workspace: Don't freeze the layout when there's no layout yet
On some touchpads/laptops, the swipe gesture to open the overview can be
performed so fast, that it starts and ends in between two frames. Now
when this happens, and the gesture ended with too little movement to
confidently say the user intended to open the overview, we'll close the
overview again.

While closing the overview, we freeze the layout of the Workspace in
order to avoid changes to windows messing with the animation. This means
that in the case described above, we freeze the layout even before the
first frame of the opening animation happens. No frames being drawn also
means no allocations happening, and since we create this._layout in
vfunc_allocate(), this means that on the first allocation cycle of the
overview we'll see this._layoutFrozen = true, but will also not have
a this._layout nor this._windowSlots.

This creates an annoying visual glitch where for a split second all
the windows disappear (overview is visible but no WindowPreviews get
allocated).

To fix this, force creating a layout on the first allocation cycle, even
if the layout is currently frozen.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2203>
2022-03-06 00:00:46 +00:00
Florian Müllner
26235bbe54 js: Use (dis)connectObject()
Start using the new methods to simplify signal cleanup. For now,
focus on replacing existing cleanups; in most cases this means
signals connected in the constructor and disconnected on destroy,
but also other cases with a similarly defined lifetime (say: from
show to hide).

This doesn't change signal connections that only exist for a short
time (say: once), handlers that are connected on-demand (say: the
first time a particular method is called), or connections that
aren't tracked (read: disconnected) at all.

We will eventually replace the latter with connectObject() as
well - especially from actor subclasses - but the changeset is
already big enough as-is :-)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
2022-03-04 14:14:37 +00:00
Florian Müllner
2b45a01517 cleanup: Use new indentation style for object literals
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.

But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).

And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
2022-02-23 12:23:52 +00:00
Daniel van Vugt
ed7fe756ef workspace: Fix a signal leak in WorkspaceBackground
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2143>
2022-02-01 12:11:54 +00:00
Sebastian Keller
b90a6d6b14 workspace: Move fading minimized windows out of allocation
eee2ccac fixed window opacity being changed outside of transitions but
resulted in the final step of the transition, that would set the window
to fully opaque, being missed.

This change now moves the opacity change entirely out of allocation and
instead follows the adjustment changes directly, which still fixes the
original bug and ensures the opacity is also applied for the last step
in the transition.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4561
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1957>
2021-09-01 15:02:47 +00:00
Ivan Molodetskikh
b21b43e318 workspace: Update bg border radius in constructor
Otherwise non-zero initial value of stateAdjustment will produce
incorrect radius.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1964>
2021-09-01 11:01:04 +00:00
Daniel van Vugt
7c1b30b272 workspace: Ignore new windows that appear while the overview is closing
This can easily happen if an app launches and maps a window faster than
the overview closes. We don't want the window clone appearing and then
suddenly disappearing in that case.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1440>
2021-08-19 15:44:34 +08:00
Daniel van Vugt
cc2af75fb4 workspace: Remove skip-taskbar windows while the overview is shown
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.

This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.

https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137
https://bugs.launchpad.net/bugs/1936643

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
2021-08-11 15:15:03 +00:00
Sebastian Keller
eee2ccac7a workspace: Only change opacity of minimized windows during transitions
Dragging a window preview in the overview is supposed to change the
opacity of the dragged actor. This however fails for minimized windows,
because Workspace::allocate() also changes the opacity of those. The
allocation gets triggered by removing the window actor from the
workspace when starting the drag. Avoid this by only changing the
opacity during the overview transitions.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4292

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1847>
2021-07-23 12:38:12 +02:00
Marco Trevisan (Treviño)
f30fa1adc7 WorkspaceBackground: Fully take care of workarea geometry on allocation
The background group is currently allocated taking care of the workarea
x, y offset but not of its width/height and this may lead to building a
wrongly sized workspace view when the workarea size is not matching the
monitor size (like when there are struts set).

So, take care of the difference between the workarea and monitor
absolute end coordinates to allocate the background scaled content box.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
2021-07-17 00:25:50 +02:00
Sebastian Keller
234024c4f4 workspace: Update WorkspaceLayout workarea on changes
Previously the workarea was only set on construction and then never
updated. As a result the preferred width and height as well as the
allocation were based on an outdated workarea size when it changed after
construction. This for example was happening during the startup
animation, for which the WorkspaceLayout is constructed before the panel
is shown. This caused the workspace in the overview to be slightly
smaller when it is first shown and the overview closing animation to
not expand the workspace to the correct size the first time it is
closed.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3945
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3816

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1771>
2021-05-11 02:36:54 +02:00
Jonas Dreßler
4e83aaf850 workspace: Extend clip when animating from window picker to app grid
We want to clip the Workspace actor in the appGrid state of the overview
in order to make sure windows that overflow the monitor don't spill out.
So far we had commit b1970b95b8 for that.

Now since the last commit, window previews always slightly overflow the
allocation with their icons. That means a part of the window icon gets
clipped away as soon as the transition to the appGrid starts, which
looks weird.

Fix that bug in the transition by slightly extending the clip downwards
when animating between the window picker and the app grid state. The
extra height we extend the clip by is controlled by the overviewState,
which means we extend the clip by the full icon overlap in the window
picker state, but don't extend the clip at all when in the app grid
state.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
2021-05-04 14:16:46 +00:00
Jonas Dreßler
fcc80407ea workspace: Make window preview overlays overflow the allocation
We want to use as much space as possible for showing window previews in
the overview, and the title and close buttons of those windows are only
visible on hover, so we can show them above anything if we want.

On both primary monitors and secondary monitors, there's a certain free
space available towards the bottom edge of the monitor (on the primary
monitor we show the dash there, and secondary monitors just scale down
the Workspaces). We can make use of this by checking how much free space
there is available from the bottom edge of our allocation to the bottom
edge of the monitor, and then aligning the window previews to make full
use of this space.

So stop adding any padding to the edges of the Workspace, which will
make the windows a lot larger and completely fill the Workspaces
allocation.

The left, top and right monitor edges should always be far enough away
to accomodate the close button and hover scale-up of the window. Only
with the bottom edge of the monitor we have to be a bit more careful
(the overflowing height of the window title is quite big), so there we
check if enough free space is available. If there isn't enough free
space, we simply apply a bit of bottom padding again and shift the
window up.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
2021-05-04 14:16:46 +00:00
Jonas Dreßler
dda23fc4c6 workspace: Center window previews horizontally and vertically
Window previews looks slightly offset to the left and top right now
because we don't use the same padding on all edges of the Workspace. We
do that because the oversize and overlap of the window previews is
different on all sides (for example the bottom overlap is very large
because there we show the window title).

To make sure window previews are always perfectly centered on the
Workspace, only use the largest one of the oversize values as spacing
and padding, and add the larger one of the overlap values for the
vertical padding in addition.

With this, we now center the window previews on the Workspace while
never overpainting the allocation of that Workspace to show overlays.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1670>
2021-04-08 17:51:15 +00:00
Jonas Dreßler
59b97a3095 workspace: Use Util.lerp() instead of actor box for interpolating
Instead of interpolating our workspace and layout boxes for each child
using clutter_actor_box_interpolate(), use our Util.lerp() function and
stay in JS land instead.

This is quite a large performance improvement since it avoids
heap-allocating a new ClutterActorBox for every child. With this, we're
finally at a duration of 1.0 ms to allocate the Workspace with 20
windows.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
650e0960a2 workspace: Get some values outside the children loop when allocating
It turned out that getting properties and saving them to a variable
outside of loops instead of accessing them everytime inside the loop can
have significant impact on performance, so do that in Workspaces
vfunc_allocate().

Here the impact is not that large, about 0.05 ms with 20 open windows,
that still seems worth it though.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
5792b98f79 workspace: Don't create useless childBox
Creating a ClutterActorBox here is superfluous, we actually create and
assign a new box to this variable inside the loop.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
ec4b9b8894 workspace: Don't do checks in animateAllocation()
These checks aren't needed since Clutter should enforce this for us
already and skip the implicit transition when possible. This gets our
time spent in vfunc_allocate() down to 2.0 ms with 20 windows

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
3e9a08a2e1 workspace: Use set_origin/set_size instead of properties when allocating
Setting four properties is more expensive than calling two C functions,
so move to set_origin()/set_size() calls for our ClutterActorBox
handling.

This gets us down to an average time of 2.1 ms spent in vfunc_allocate()
with 20 windows

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
e75f3a8aed workspace: Iterate windowSlots directly when allocating
We can save a little bit of time in this loop by iterating directly
over the windowSlots array instead of iterating through children and
then performing a search for the windowSlot. This saves more time and we
only spend 2.2 ms instead of 2.3 ms in vfunc_allocate() now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Ivan Molodetskikh
35fb221a7e workspace: Check if index is valid before using it
If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547

I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1727>
2021-03-03 19:56:45 +00:00
Ivan Molodetskikh
0a144ee54f workspace: Fix switched arguments
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1738>
2021-03-03 15:08:17 +00:00
Jonas Dreßler
31d7770eeb workspace: Center-align window previews if there's only a single row
Instead of always aligning window previews vertically at the bottom of
their row, only do that if we have multiple rows. If there's only a
single row of windows, align every window vertically centered.

This is a very small step towards the new layout for window previews in
the overview, but since the release of 40 is getting nearer and nearer,
changing more is not feasible anymore.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1737>
2021-03-03 15:02:52 +01:00
Jonas Dreßler
99378b6dae workspace: Scale down wallpaper by a fixed number of pixels
To ensure the workspace thumbnails are vertically closer to the window
picker than to the search, scale down the wallpapers by a fixed number
of pixels. Using 24 px for this means we'll take of 12 px at the top and
12 px at the bottom of the wallpaper, that's a better strategy than
always scaling it by a fixed factor since it doesn't change with the
monitor size.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
2021-03-03 12:08:58 +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
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
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
Sebastian Keller
c01973055f workspace: Ensure that _createBestLayout() always returns a layout
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>
2021-02-16 21:24:27 +00:00
Florian Müllner
2beca14b8d windowPreview: Tie icon scale to overview state
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>
2021-02-12 19:48:43 +00:00
Georges Basile Stavracas Neto
86cefd906b workspace: Disable overlay for inactive workspaces too
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>
2021-02-11 17:21:48 +00:00
Georges Basile Stavracas Neto
2e817d3fa8 workspace: Always leave overview when in app grid state
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>
2021-02-11 17:21:48 +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
1adcbaab46 workspacesView: Derive workspace state from fit mode
Derive the workspace state WorkspacesView's workspaces from the fit mode.
Extra workspaces still run the zoom animations as before.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Georges Basile Stavracas Neto
176ea3b1ef workspace: Split preparation steps from zoomFromOverview
Next commit will bind the workspace state adjustment to the snap
adjustment in WorkspacesView, and we'll need the preparation
steps but not the easing of the state adjustment.

Split preparation steps from zoomFromOverview() into a new method
prepareToLeaveOverview().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Georges Basile Stavracas Neto
4cf5b4a6d8 workspacesView: Scale inactive workspaces
As per the latest mockups, then horizontally snapping, the active
workspace should be highlighted. Because WorkspacesView clips to
allocation, we cannot simply scale up the active one. Instead,
scale down the inactive ones.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Florian Müllner
3abfc25858 workspacesView: Always use ZOOM transition
Workspaces are now always shown, so the code path to fade windows
instead of zooming out is dead now; remove it.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Florian Müllner
252f2f5144 cleanup: Define GObject accessors in camelCase
gjs is smart enough to match a propertyName getter/setter to the
corresponding property-name GObject property, so use that and get
rid of the eslint camelcase rule exceptions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Sebastian Keller
454394a267 workspace: Handle window-added and removed signal after window tracker
The new window preview overlay requires getting the app icon for a
window from the window tracker when it gets initialized. The window
tracker listens for the same 'window-added' signal on the MetaWorkspace
that the gnome-shell Workspace listens for to add the window preview.

The window tracker however reconnects all its signal handlers whenever
the number of workspaces changes, which means that its signal handlers
get called after the ones in Workspace ones. So by the time the
'window-added' handler in Workspace is called, the window tracker does
not have an app associated with the window.

To fix this ensure that all window related signal handlers in Workspace
are run after the ones in the window tracker.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3656

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1625>
2021-02-02 23:11:06 +01:00
Florian Müllner
27a427421e workspace: Add some padding around window previews
Commit 059ea64 removed the workspace padding after moving the
background into the workspace. However some whitespace around
window previews is still a good idea, and will be necessary
soon as we are about to indicate focus by slightly scaling up
the active preview, and don't want previews to be clipped by
the workspace in that case.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00