Commit Graph

7765 Commits

Author SHA1 Message Date
Jonas Dreßler
9f415f1c89 keyboard: Make a few functions private
Now that we got rid of the external calls to setCursorLocation(), we can
make that private. animateShow() and animateHide() weren't called from
outside anyway, so let's make those private, too.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
f3f0396b7e keyboard: Clear keyboard rest timer when opening immediately
When immediate is true on open(), we want to show the OSK immediately,
it also makes sense to cleanup the keyboard rest timer in that case.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
cb68bbee36 keyboard: Rename focusTracker "reset" signal to "window-grabbed"
What this signal does is fire when a window was grabbed. A receiver
might want to do something special when a window was grabbed, whereas
"reset" can mean anything. Rename the "reset" signal to
"window-grabbed".

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Florian Müllner
16c7739170 messageTray: Remove deprecated code
Originally the Source method for showing notifications was "notify",
which had to change when turning it into a GObject subclass to not
clash with g_object_notify().

That change happened during the 3.36 cycle, so extensions have had
two releases (a year) to adapt to the replacement. That seems long
enough, so remove the deprecated compat code.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1749>
2021-03-10 15:17:52 +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
afb56df55c windowPreview: Subclass a C actor
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.

This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.

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
Jonas Dreßler
04c781674c Move WindowPreviewLayout from JS to C
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.

We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.

In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
2021-03-09 15:40:49 +00:00
Jonas Dreßler
5de9166f7a panel: Only update appMenu icon when the app actually changed
Right now we always recreate the icon of the appMenu when calling
_sync(). This will relayout the panel everytime we open the overview,
because we call _sync() in that case.

We can easily avoid that by only recreating the icon actor in case the
app that's opened actually changes. This gets us close to doing no more
relayouts of the panel when opening the overview.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
2021-03-09 13:15:09 +00:00
Jonas Dreßler
e6c1db2bc8 panel: Don't completely hide AppMenuButton when invisible
We already set the AppMenuButton to be non-reactive and transparent when
we hide it. Hiding it completely using clutter_actor_hide() will
additionally make it no longer affect layout and thus queue a relayout.

Since we hide the appMenu in the overview and we want to avoid
relayouting the panel when entering and leaving the overview, don't
completely hide the AppMenuButton to avoid queueing this relayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
2021-03-09 13:15:09 +00:00
Florian Müllner
fb1ab4f20b windowManager: Limit super-scroll handling to normal mode
The overview has it's own workspace scroll handling, and we don't want
to switch workspaces in other modes. Limiting the scroll-event handler
to NORMAL mode matches the swipe tracker used by WorkspaceAnimation,
and allows for other uses of scroll events (like scrolling in the
alt-tab popup).

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1746>
2021-03-09 12:28:36 +00:00
Sebastian Keller
b853316498 ctrlAltTab: Fix usage of bind_cairo_surface_property
This updates the use of bind_cairo_surface_property for the changes
from d7cb2eeebc. Now this function returns a StImageContent and not
an Actor like the following code expects, so wrap it in a StIcon.
Also the function lost its size argument.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
2021-03-08 09:21:25 +00:00
Jonas Dreßler
7a57528bd7 workspaceThumbnail: Update visibility when showing the overview
There's currently a bug that we continue showing the workspace minimap
when the number of workspaces changes back to 1 during the session (ie.
outside the overview). Fix that by also updating the workspaceThumbnails
visibility when entering the overview.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1741>
2021-03-04 12:39:37 +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
Florian Müllner
30f0c9f943 workspaceThumbnails: Update indicator on workspace changes
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.

To fix that, update the indicator on workspace changes as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Florian Müllner
fac50fb50e workspaceThumbnail: Queue state update after expanding
New workspaces are added in two steps, first the minimap expands to make
room for the new thumbnail, then the thumbnail animates in. However we
currently don't queue a state update after the first step, so the second
one only happens after one is queued by some other event (like a workspace
switch).

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
2021-03-03 18:04:13 +00:00
Jonas Dreßler
7f99655067 iconGrid: Only animate items when we actually need it
Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.

This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:16 +00:00
Jonas Dreßler
7771bf4437 iconGrid: Save class variables to local ones
It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.

This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:16 +00:00
Jonas Dreßler
7a5650d868 iconGrid: Bail out of getRowPadding early if we'll return 0
This gets our time spent in vfunc_allocate() down again by ~0.1 ms from
1.4 ms to 1.3 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
0fd394d4ca iconGrid: Don't update pages in vfunc_allocate()
vfunc_allocate() is a hot path, and we don't want to do expensive stuff
there, so avoid updating the pages, which seems unnecessary anyway.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
0978b87e65 iconGrid: Get max child size using existing array of visible children
Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.

Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
8e93806453 iconGrid: Cache visible children of pages
We need to access the visible children of a page in inside
vfunc_allocate(), and since getting those children is quite slow (it
involves iterating over all the children of the actor) let's avoid that
and cache the array instead.

This reduces average time spent in vfunc_allocate() of the iconGrid from
1.6 ms down to 1.4 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +00:00
Jonas Dreßler
b3c46a33c0 iconGrid: Cache max size of children
We call this._getChildrenMaxSize() from the allocate() vfunc of
IconGridLayout. Since the function is quite expensive, it slows the
layout process down a lot, so instead of re-calculating it on every
relayout, cache the max size of children.

This makes the average time spent in vfunc_allocate() of the iconGrid go
down from 2.3 ms to 1.6 ms.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
2021-03-03 17:59:15 +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
9b9be4a1a5 workspace: Decrease spacing between workspaces in the window picker
Use a bit less spacing between the workspaces in the window picker, this
uses more of the available space and makes it easy to take a peek at
adjacent workspaces.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
2021-03-03 12:08:58 +00: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
Georges Basile Stavracas Neto
9bce2a02be overview: Don't show black panel on startup
The back → transparent transition gives it a very bad look when
booting and running the startup animation.

Use the same transition duration hack to ensure that the panel
starts completely transparent.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Georges Basile Stavracas Neto
72505227b7 panel: Bind style to corners' style
There's this little hack that we do to match the panel transition from
transparent to black with leaving the overview via swipe down. The only
problem is that, while the duration of the panel transition itself is
matches, the corners don't, and they get out of sync.

This isn't very noticeable with the swipe gesture, but it'll be much
more prominent when booting straight into the overview.

Bind the 'style' property of the panel to the corners', so that the
transition duration hack applies to all of them.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +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
Georges Basile Stavracas Neto
e3f12e3e23 layout: Update workspace struts even while starting up
We want to avoid updating the input region on startup, since it incurs
in roundtrips to the X server, but not workspaces struts, since they
affect the visible clip of wallpapers in the workspace. Since next
commits will make the overview be the after-boot screen, we really
don't want the wallpaper to be clipped wrongly.

Allow updating regions while starting up, but only workspace struts.
Make sure input is not updated by accounting for 'this._startingUp'
on 'wantsInputRegion'.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Georges Basile Stavracas Neto
bc0974618f layout: Don't build input region rects on Wayland
This is an X11-specific routine, and building the list of input region rects
on Wayland is a waste, since it incurs in many trampolines only to throw them
in the trash.

Don't build input region rects on Wayland. By modifying the 'wantsInputRegion'
variable, it also skips actors that only update input, which is another small
optimization for Wayland.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Georges Basile Stavracas Neto
ba0b9239d3 layout: Allow updating struts in Overview
LayoutManager doesn't update struts when there's any modal running. Turns
out, the Overview itself is a modal. That, and the fact that the Overview
will be the startup state, prevents the workarea to be updated.

Allow updating struts when there's no other modal than the Overview.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
2021-03-02 23:14:07 +00:00
Remi Salmon
9cd211a99a status/network: Use the same signal strength values as GNOME Settings
Be consistent and use the same wifi signal strength thresholds that are
used by Settings to ensure that the signal strengths look the same in
Settings and gnome-shell.

See https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/panels/netwo>
for the	values used in Control Center.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1432>
2021-03-02 23:07:01 +00:00
Carlos Garnacho
9b24d9c4c0 appDisplay: Don't reset adjustment on ::pages-changed
Let the goToPage call afterwards to take precedence, instead
of resetting the adjustment (thus the view) on the side.

This resulted in strange state when the last page contains
a single icon, and it is dragged. The last page being emptied
triggers a pages-changed signal, which half resets the view
to the first page while DnD is ongoing.

Letting goToPage do its business means we neatly clamp to the
closest page to currentPage, the last page in that case.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
ec223f31d9 appDisplay: Slide page hints along page switching
When clicking on the page hints, the hint rectangles being visible
in place and not moving together with the page is a bit too
distracting.

Since the page hints are not part of the iconGrid hierarchy and
we have just 2 general ones for prev/next page (i.e. no page
associated), do this sliding via some smoke and mirrors: We don't
slide the page hints, but a parent container for both of them, and
we also control opacity so that the container is fully transparent
mid-page. At the point it is transparent, the container can be
snapped to the other side of the page, and faded back in as it
slides together with it, so it always looks like it goes away and
comes from the right sides.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
9e5b357b0b appDisplay: Adapt to available extra space showing icon grids
Depending on the available horizontal space, we may want to manipulate
the icon grid and scroll view spacing to result in an optimal layout
that has space left to preview prev/next pages.

The main change here is that, when adapting to the available size, the
space given to a page does not necessarily match the available space,
as we need to be able to show more than one page at a time.

With this decoupling of available and page sizes in place, we now know
how much space there is available in order to extend the padding between
pages, or the fade effect applied to the previewed pages.

Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more
on the StScrollView::content-padding property.

All put together, gives us proper space management from ultra-wide
displays, to display ratios that are close to the optimal grid ratio.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
ffe11e0560 appDisplay: Add carousel arrows to app grid
These only show during navigation (not DnD), along with the
previewed page.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
a00db66ffe js/appDisplay: Implement side page previews while DnDing
When DnDing an icon, we show both previous/next page, and optionally
a "placeholder" actor to allow creating new pages. These sides on the
scrollview are drop targets themselves, allowing to drop an app onto
the next/prev page without further navigation.

Still, preserve the checks to maybe switch to prev/next page without
finishing the DnD operation, for finer grained operations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
d75ed55ed8 js/appDisplay: Implement navigation of pages by hovering/clicking edges
Add the necessary animations to slide in the icons in the previous/next
pages, also needing to 1) drop the viewport clipping, and 2) extend scrollview
fade effects to let see the pages in the navigated direction(s).

The animation is driven via 2 adjustments, one for each side, so they
can animate independently.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
f31c49c40e js/appDisplay: Generalize app scrollview CSS
We want to show left/right side pages during navigation, also in
FolderViews. Let this scrollview use the same style than the "all
apps" one, and generalize the name a bit.

This will compress the scrollview horizontally, so there's actual
overflow space to show these pages.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Carlos Garnacho
f60a469a34 st/scroll-view: Make fade effect take ClutterMargin
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.

This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.

While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
2021-03-02 22:02:56 +00:00
Florian Müllner
260f5b0b8d workspacesView: Add minimap on secondary monitors
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.

That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
082eedd968 workspacesView: Decrease workspaces size on external monitors
Now that the backgrounds was moved into workspaces, the fullscreen
views on secondary monitors are visually inconsistent with the
primary view, as there's no dash or search entry that reduces the
available height and allows adjacent workspaces to peek in.

Address this by adding padding above and below the view, so that
it is limited to 70% of the available height.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
a8e6403045 workspacesView: Split out SecondaryMonitorDisplay
Right now the handling of external monitors is relatively simple, and
consists of putting either an extra workspace or a full view on the
monitor, depending on the workspaces-only-on-primary setting.

We are about to tweak the behavior on secondary monitors, prepare for
that by splitting out an intermediate actor that manages the views on
non-primaries.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
40121bbe4b workspacesView: Center extra workspace
At the moment views on non-primary monitors take up the entire work area,
so simply allocating the available size works. However we'll soon shrink
the views a bit to match the visuals on the primary monitor. As workspaces
keep the ratio, reducing their height will also reduce the width; override
the default allocate() to keep the extra workspace horizontally centered.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +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
4eb31e4e18 workspaceThumbnails: Immediately initialize should-show
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
09afaf0745 workspaceThumbnail: Initialize porthole to work area
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.

That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
2021-03-02 21:56:30 +00:00
Florian Müllner
945e947a54 workspaceThumbnails: Disconnect signals on destroy
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.

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
Carlos Garnacho
46361c9a04 appDisplay: Move onto the correct page while DnD on both LTR/RTL
Look up the next page correctly for the overshoot coordinates, given
the text direction. We don't need to look whether there is a next
page either, as goToPage() checks that it's the case.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3778
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1734>
2021-03-01 18:34:46 +01:00
Sebastian Keller
a6588d054f windowPreview: Unset selected if window was clicked to switch workspaces
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1717>
2021-03-01 14:45:50 +00:00
Florian Müllner
e2c1407153 overview: Unset visibleTarget on gesture end
The property describes the target visibility (that is, the visibility
that will be set after the ongoing transition), and is therefore updated
at the start of the transition rather than from hideDone().

The overview gesture currently misses resetting it at the end, so it
is only updated to the correct state the next time the overview is
entered.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1726>
2021-03-01 13:38:42 +00: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
Abderrahim Kitouni
48ae38c52d windowManager: Use Clutter default text direction
This code was copied from workspacesView which used the widget's text
direction, but it is no longer in a widget

Fixes #3780

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1724>
2021-02-26 18:10:16 +01:00
Florian Müllner
49b7973177 workspaceThumbnail: Consider porthole offsets
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>
2021-02-26 14:36:39 +01:00
Abderrahim Kitouni
c90bde464a js: Require Soup 2.4
Soup 3.0 is a thing now

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1720>
2021-02-26 12:28:21 +00:00
Michael Terry
8850c579da endSessionDialog: Only show logout inhibiting apps
Apps that only inhibit other kinds of activity (like idle or suspend)
don't need to be shown to user when they are logging out.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1424>
2021-02-24 15:31:03 +00:00
Sebastian Keller
ef5b92c596 windowPreview: Ensure scaling is limited to defined size increase
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>
2021-02-24 09:58:31 +00:00
Florian Müllner
ef777426d2 lightbox: Fix shader effect
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>
2021-02-24 09:52:45 +00: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
Jonas Dreßler
63a96a7111 workspacesView: Take scale factor into account to calculate spacing
This is a statically defined size and we need to adjust for scaleFactor
ourselves, so do that and multiply those two values by the scale factor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1701>
2021-02-21 16:25:17 +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
Georges Basile Stavracas Neto
9d4f017248 workspacesView: Only clip non-primary workspace views
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>
2021-02-21 15:47:12 +00:00
Florian Müllner
55e08a3a2f welcomeDialog: Hide overview when taking tour
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>
2021-02-19 17:18:50 +01: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
7d40930cd6 windowPreview: Scale up by the same extra size for every window
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>
2021-02-19 11:23:07 +00:00
Jonas Dreßler
3795ccbcf3 windowPreview: Use a proper spacing between icon and title
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>
2021-02-19 11:23:07 +00:00
Florian Müllner
ece5220b42 windowManager: Keep a minimum number of workspaces
The scaled down workspace in the window picker looks lonely when there's
no adjacent workspace peeking in. Avoid that by always keeping a minimum
of two workspaces.

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:05 +01:00
Florian Müllner
2fdee8e444 workspaceThumbnails: Only show for more than two workspaces
As adjacent workspaces now peek into the window picker, the first
two workspaces are already accessible without the minimap. Hide
it in that case to give more space to the window picker, and to
not clutter the overview for users who aren't using workspaces.

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:05 +01:00
Florian Müllner
d3a1557864 workspaceThumbnail: Do not update scale while collapsing
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>
2021-02-19 01:13:05 +01:00
Florian Müllner
7b1b04f95a workspaceThumbnails: Delay workspace removal while collapsing
Animating a thumbnail removal while also collapsing the minimap
itself doesn't look good, so keep the stale thumbnail until the
minimap is hidden.

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:05 +01:00
Florian Müllner
a2751a1b26 workspaceThumbnails: Don't animate thumbnail additions while hidden
This is not just an obvious mini-optimization, it also ensures that we
don't start showing the minimap with an ongoing thumbnail transition.

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:05 +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
bf8e762178 workspaceThumbnail: Base n-workspaces on number of thumbs
It's what we base our size request on, and what we actually allocate.
The difference usually doesn't matter right now, but will soon when
we animate the minimap itself.

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
2e9715c97e workspaceThumbnails: Actually use vscale parameter
We pass two scales to setScale(), but only use the first one for
both horizontal and vertical scaling. We'll soon have a use case
for using a different scale for each dimension, so start using
both parameters.

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
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
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
Georges Basile Stavracas Neto
ac6337848f workspacesView: Disable mouse drag to switch workspaces
During the user research, it was found that users would instinctively
drag the workspace horizontally but would often, in the process,
accidentally drag a window.

Disable dragging workspaces using the cursor for now.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3742
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1694>
2021-02-18 09:43:02 -03:00
Carlos Garnacho
0b16565e70 keyboard: Handle edge drag gesture cancellation
Hide the keyboard again if the gesture happens to stay/return
within it's activation threshold.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
c62177e669 keyboard: Make OSK follow gesture progress
With all other gestures offering live feedback of progress, seems
to make sense to update the "swipe from bottom edge to show OSK"
gesture as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
8526776b4a keyboard: Use translation-y property for focus window animations
Just the intermediate state, we still need to synchronize visual and
real window position after the animation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
3346e9923b keyboard: Move monitor management to KeyboardController
Instead of setting it deep down, manage it at the higher level.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
0a12405e01 keyboard: Simplify focus window tracking
Keep the focus window in a single field, and optionally animate
depending on keyboard visibility.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
a6a4e0a504 edgeDragAction: Add signal to notify about progress
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
8e73143b24 keyboard: Drop layoutManager's keyboard-visible-changed
Since now the signal is emitted and handled all within keyboard.js,
use an internal signal to manage keyboard visibility and gesture
enablement.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
0580fe6eff windowManager: Move OSK gesture to KeyboardManager
It would be nice to get finer control over the keyboard slide
gesture and animation. Move the gesture bits so they are together
at keyboard.js.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
f52cafeb4a layout: Move keyboard slide animation to keyboard
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>
2021-02-17 15:45:01 +00:00
Carlos Garnacho
76836fe388 overview: Synchronize panel opacity with overview leave animation
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>
2021-02-17 14:06:11 +01:00
Carlos Garnacho
f7f46ca9ac overview: Clean up dead code
These unused functions accessed undefined functions on a now undefined
variable/class. This vestigial code can go away.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
2021-02-17 14:06:11 +01: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
Carlos Garnacho
f69727464c workspacesView: Initialize/update swipe orientation before gesture
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>
2021-02-17 14:06:11 +01:00
Carlos Garnacho
a498d8577e workspacesView: Check for primaryView being null
This is possible according to the getter, and triggers warnings
seen when going back from overview via gestures.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
2021-02-17 14:06:11 +01:00
Carlos Garnacho
ea881ed077 swipeTracker: Reject touch swipes in the wrong directions
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>
2021-02-17 14:06:11 +01:00
Carlos Garnacho
504ca7d4c3 swipeTracker: Try harder to start touchpad gestures with a direction
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>
2021-02-17 14:06:11 +01:00
Florian Müllner
e135f077fb swipeTracker: Reject touchpad swipes in the wrong directions
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>
2021-02-17 14:06:11 +01:00
Sebastian Keller
8edfe1dcf6 dnd: Remove pointless scale factor from restore position
Since 629b7394 we don't use the preferred size anymore, but the original
allocation, so this scale factor would always be 1.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
2021-02-17 10:12:00 +00:00
Sebastian Keller
a24a16c5ac dnd: Also consider indirect scaling of dnd actor
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>
2021-02-17 10:12:00 +00:00
Marco Trevisan (Treviño)
cf41f4a527 searchController: Get rid of activePage reference in key handling
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>
2021-02-17 02:31:32 +01: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
Jonas Dreßler
e65e5edee6 appDisplay: Use icon-size instead of width/height for system actions
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>
2021-02-16 13:56:20 +00:00
Jonas Dreßler
8f9d6a4c13 appDisplay: Use new indentation style
Otherwise eslint will complain about the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
2021-02-16 13:56:20 +00:00
Sebastian Keller
1bd2b0123e windowPreview: Consider chrome overlaps when offscreening for opacity
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>
2021-02-16 13:29:00 +00:00
Sebastian Keller
8d5fb73695 workspacesView: Don't invalidate allocation before using it for gesture
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>
2021-02-16 03:50:52 +01:00
Sebastian Keller
629b7394f7 dnd: Set dnd actor size instead of scaling it when reparenting
Previously the actor could end up using its natural size and then get
scaled down to its allocation before reparenting. This however could
affect the layout of the widget due to the larger size. To ensure the
widget looks the same after reparenting set the size to its original
size.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1680>
2021-02-16 01:07:23 +01:00
Carlos Garnacho
863ba76675 messageTray: Drop hack to keep track of X11
This is here to cater for lost events while the pointer wanders
into untracked shell UI (thus not part of the input region under
X11). Let mutter handle this situation instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
2799760244 windowManager: Drop sync_pointer() after relayouts
We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
2445212e35 messageList: Drop sync_pointer() after relayouts
We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
cbde13fc65 overview: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
0141b66d23 grabHelper: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
f1437506ea dnd: Avoid sync_pointer after pop_modal()
This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>
2021-02-14 13:57:56 +00:00
Carlos Garnacho
28f73a175c windowManager: Do not set Wacom LED state through g-s-d
This piece of machinery is going away, in favor of the own kernel's
support.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1075>
2021-02-13 15:52:55 +01:00
Lucas Werkmeister
bbf1fc28ca lookingGlass: Let history trim input
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>
2021-02-13 08:58:20 +00:00
Lucas Werkmeister
df94055c58 runDialog: Let history trim input
Checking whether the item is empty is now the history’s job, per the
previous commit. The history also returns the trimmed input for us, so
we can avoid doing that work twice.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
2021-02-13 08:58:20 +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
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
1b51ae150d searchController: General cleanup
Fix style issues, such as indentation and == → ===. Simplify
getTermsForSearchString() by removing one variable.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
2021-02-11 21:14:36 +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
Jonas Dreßler
3510b88bdc screenshot: Remove shooter from sender in finally block
We do this in both the try{} and the catch{} block, so we might as well
put it into a finally{} block.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
2021-02-11 18:51:40 +00:00
Jonas Dreßler
c1bfdd74d8 screenshot: Fix slow audiovisual feedback on when taking screenshot
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>
2021-02-11 18:51:40 +00:00
Jonas Dreßler
461c65c93b screenshot: Replace template strings with .format()
CI will complain when we add screenshot.js to the POTFILES in the next
commit because gettext doesn't like template strings, so make CI happy
and switch to .format() instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
2021-02-11 18:51:40 +00:00
Brion Vibber
f9652aab82 Fix for screenshots when pictures path is unavailable
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>
2021-02-11 18:51:40 +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
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
ca066a4ba6 workspacesView: Use calculated workspace state for progress
It works just like before, except that this has the nice side effect
of not changing the workspace mode when leaving the overview from
the app grid state.

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
a9f11b1f5a workspacesView/workspacesDisplay: Remove parent opacity hack
Now, we set WorkspacesDisplay's opacity directly, so there's no
need to have this parent → child glue code anymore. Remove it.

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
4cf5898d85 viewSelector: Remove pinch gestures
It'll be replaced by a 3 finger gesture that sticks to fingers
and progressively transitions between states.

Remove both pinch and touchpad pinch gestures from ViewSelector.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
2021-02-11 15:50:31 +00:00
Georges Basile Stavracas Neto
cbe0180f47 viewSelector: Drop edge drag gesture
It doesn't use any ViewSelector's API anymore, and its functionality will be taken
over by the 3 finger gesture.

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
bce67a27cc viewSelector: Move 'toggle-overview' shortcut to overview
It is handled there already, there's no reason for it to continue
to be in ViewSelector.

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
d221215ab6 workspacesView: Derive workspace mode from overview state
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>
2021-02-11 15:50:31 +00:00
Florian Müllner
741d6abb97 workspacesView: Add primary view to workspaces display
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>
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
Pascal Nowack
d02612e790 ui/windowManager: Fix horizontal scrolling when smooth events are used
Currently, gnome-shell uses the wrong scrolling direction for
horizontal scrolling events.
When dx < 0 for a smooth scroll event, then the scrolling direction is
supposed to be Clutter.ScrollDirection.LEFT, instead of
Clutter.ScrollDirection.RIGHT, as dx is smaller than 0.

Fix this issue by swapping the values LEFT and RIGHT.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1665>
2021-02-11 15:43:19 +01:00
Florian Müllner
21faae480e polkitAgent: Ensure cleanup if dialog wasn't shown
It is possible for an initiated session to complete without
a request if polkit can authenticate the action without user
input. We fail to clean up after ourselves in that case, as
the cleanup is done after the dialog is closed.

The dialog can still be shown when the code that hides existing
dialogs while the screen is locked shows it on unlock. But as
the session was closed, the dialog is now defunct and cannot
be dismissed by the user.

Fix this by running the cleanup on close() when the dialog
wasn't shown.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662>
2021-02-11 13:48:54 +01:00
Florian Müllner
3a9acb9602 dash: Re-fittsify
Now that the dash is no longer attached to a screen edge, it lost
its "infinite width" (Fitts' law). Restore it by moving the visible
bar into a separate layer underneath the actual icons, extend the
icons to the bottom edge, and replace the margin around the dash
with padding inside the icons.

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
5c31ef6ae2 dash: Reindent some more code
Again we're about to touch it.

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
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
9aa25eaa0b dash: Consider additions for separator visibility
The children variable holds the icons that were originally in
the dash. For the separator visibility, we should consider the
icons that are in the dash after the update, so we must consider
additions as well as removals.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1659>
2021-02-10 09:09:34 +00:00
Abderrahim Kitouni
9aae1df7a6 workspacesView: Fix off-by-one error
This is basically 9f0e7632a6 ported over ed1170906b which was dropped this
fix when copying things around.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1655>
2021-02-09 09:40:29 +00:00
Alexander Mikhaylenko
2b9cf73309 workspacesView: Enable long swipes
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
2021-02-08 22:20:26 +00:00
Alexander Mikhaylenko
16f74ebc57 swipeTracker: Add allowLongSwipes property
Since we now have the ability to support swiping through multiple pages,
expose it as a property.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
2021-02-08 22:20:26 +00:00
Alexander Mikhaylenko
10cafc55c1 swipeTracker: Rework end point calculation
Previously we used a bunch of heuristics for this. We checked if velocity
was directed towards the nearest snap point and its value was larger than
a threshold. If it is, we completed the swipe, otherwise we cancelled it.

This was good enough at the time, because this code was originally written
for back/forward swipe. Since then, the swipe tracker was extended to
handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
on text direction. After that it was iterated on, but never significantly
redone.

This worked well enough, but had two problems:

1. In some cases, notably overview, it may be wanted to be able to swipe
   through multiple pages at once. This wasn't really possible because we
   always picked the adjacent snap point.

2. Since we can't do that well, we want to restrict swipes to one page at a
   time. It was done in a rather hacky way by clamping the position into
   [-1, 1] range from the place where we started the swipe. This works
   if we start the swipe from idle position, but if an animation was
   already going, the range would be clamped to arbitrary values, and very
   likely containing only one snap point, which we already swiped past at
   this point. In this case, finishing the swipe would cancel it regardless
   of velocity. This means that if one tries to quickly move through
   carousel pages via swiping, half of the swipes will be inexplicably
   cancelled.

We'll use the deceleration formula from
https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
to calculate then projection point, then pick the nearest snap point and
calculate the duration as we did before. It works well enough for short
distances, but has two problems:

1. It caps the maximum distance at a pretty low value - about 5 pages in my
testing.

2. With how we pick the nearest snap point, it's too easy to accidentally
cancel the swipe,

To combat the first problem, we can modify the curve: only use linear
function at small distances, and smoothly transition it to a parabola
further.

For the second problem we can add two special cases: first, if the swipe
ended up between the initial snap point and the next one, we always prefer
the latter. Second, a good old velocity threshold for cancelling.

We'll also use a slightly smaller deceleration value for touchpad: 0.997
instead of 0.998.

Now that we can pick any snap point, the [-1, 1] clamping doesn't make
sense anymore, so instead let's replace it with a more flexible
mechanism: if we're near a snap point, pick its adjacent snap points.
Otherwise, take the two nearest snap points, and take their adjacent
snap points. This way we have 3 snap points to choose from when
starting a swipe from an idle position, and 4 if we start during an
ongoing transition.

This way, if we've just swiped from snap point n to n+1, the transition
will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
likely land on n+2. During that transition, if we swipe again, it will
likely have already passed the snap point n+1, so this time the available
snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
still complete, and so on.

This will make it easy to allow multi-page swipes as well, by just
removing the clamping.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
2021-02-08 22:20:26 +00:00
Alexander Mikhaylenko
cf87ab04aa swipeTracker: Calculate velocity using scroll history
In some cases we may get anevent with very low delta at the end of the
swipe. While we can't completely ignore them, we can smooth them using a
scroll history, similarly to what GTK kinetic scrolling does: keep track
of the last 150ms of events, and sum their deltas when calculating the
velocity.

The logic is based on what GTK does in GtkGestureSwipe and
GtkEventControllerScroll.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
2021-02-08 22:20:26 +00:00
Lucas Werkmeister
6ac32f1fc0 runDialog: Trim input before processing
This way, whitespace-only (nonempty) input gets the same treatment of
not being added to the history (see previous commit), which seems nice.

Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
2021-02-08 08:14:46 +00:00
Lucas Werkmeister
cb26a636e8 runDialog: Don’t add empty input to history
If the input is empty, there’s no point in adding it to the history –
it’ll just be mildly annoying when the user has to skip past it next
time they consult the history.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
2021-02-08 08:14:46 +00:00
Lucas Werkmeister
7bea63ae4b runDialog: Don’t treat empty input specially
Let empty input result in an error, just like other invalid commands
(bad syntax, nonempty whitespace, etc.). GLib already has an error
message “Text was empty (or contained only whitespace)” which it shows
for whitespace-only input, so letting that message apply also to empty
input makes sense.

This requires some tweaks further down the file to avoid interpreting
empty input as an empty path (relative to the home directory) and then
opening the home directory.

Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
2021-02-08 08:14:46 +00:00
Bastien Nocera
512016dcb5 main: Show welcome dialogue on first start
This hooks the recently added welcome dialogue to be shown the first
time a new session is started, and disabled after that.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3632
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1619>
2021-02-05 13:41:26 +00:00
Bastien Nocera
af4e54bfc9 welcomeDialog: Add “welcome” dialog
As designed at:
https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/greeter/welcome-dialog.png

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3632
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1619>
2021-02-05 13:41:26 +00:00
Florian Müllner
29e2b15236 data: Rename custom close icon
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.

That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.

Fix this by using a custom name for a custom icon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
2021-02-05 01:01:09 +01:00
Sebastian Keller
c61e1e5c2c mpris: Hide unused elements to leave more space for the title
The Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.

Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1632>
2021-02-04 22:42:08 +00:00
Marco Trevisan (Treviño)
e641547ddf appDisplay: Do not bind popdown call to grabHelper onUngrab
grabHelper is passing a boolean argument to onUngrab() callback function
and since commit 1acbdcc9b3 we'd end up adding it to to the callback list or
we'd try to invoke it:

 (gnome-shell:3490851): Gjs-CRITICAL **: 17:19:20.460: JS ERROR:
  TypeError: func is not a function
  onComplete/<@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:56
  onComplete@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:40
  _makeEaseCallback/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:85:13
  _easeActor/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:170:64

Use an arrow function so that we can control the parameters we pass
to popdown.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1635>
2021-02-04 21:55:34 +01:00
Razze
ed628b90d7 accessibility/keyboard: Align the panelMenu button style
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
 to have different padding from the keyboard layout pill.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
2021-02-04 20:08:29 +00:00
Florian Müllner
7aa36ad239 windowManager: Allow switching workspaces with super-scroll
So far, we couldn't allow workspace scrolling outside the overview
because scroll events were always sent to clients. However mutter
was changed recently to pass on scroll events when the mouse button
modifier (usually super) is pressed, which allows us to enable the
same workspace scrolling as in the overview now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
2021-02-04 20:04:15 +00:00
Florian Müllner
ac8246050d swipeTracker: Optionally require modifiers for scrolling
The design now calls for super-scroll for workspace switching
in the session, however it is currently only possible for
SwipeTracker to either handle scroll events or not.

In order to support the new use case, add a new :scroll-modifiers
property that allows specifying modifiers for which scroll events
are handled.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
2021-02-04 20:04:15 +00:00
Florian Müllner
26a39bdf78 workspacesView: Move workspace scroll code to windowManager
This will allow sharing the code for the new super-scroll functionality.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
2021-02-04 20:04:15 +00:00
Sebastian Keller
96d66def8c dnd: Update actor position after scaling even when animations are off
The code to update the actor position based on the cursor and current
scale was run in a 'new-frame' handler. This is working fine when
animations are enabled, but when they are turned off this does not work.
This is because the 'new-frame' signal is emitted before the changes for
that frame are applied. So with animations off the position was only
ever updated with the starting values. As a result the shrunk actor was
not being dragged by the position where it was clicked, but by where it
was clicked in the original size, which is likely not even on the shrunk
actor.

This change now also updates the position in the onComplete handler
which gets run with the final scale, even if the duration is 0.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1627>
2021-02-04 16:39:55 +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
Georges Basile Stavracas Neto
b64103efca workspacesView/workspacesDisplay: Don't sync geometry when animating
Synchronizing the actual geometry while animating from / to the overview can
break the animation. Let's prevent that. This code will go away soon anyway,
but to not lose bisectability, it's better not to leave it misbehaving until
then.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Georges Basile Stavracas Neto
ed1170906b workspacesView: Center active workspace in allocation
When vertically snapping, WorkspacesView currently allocates workspaces
side-by-side, then applies an extra step of translation to center to
the active workspace. This extra step, however, gets in our way because
now we need tighter control of the workspaces positions in allocation,
in order to properly interpolate them.

Move the translation of workspaces to the allocation code itself, and
remove the extra translation step.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Georges Basile Stavracas Neto
1359b272a4 viewSelector: Tie workspace fit mode to adjustment
Tie the fit mode adjustment of WorkspacesDisplay to the
state adjustment of AppPagesContainer, and transition to
the ALL fit mode when the app grid is visible.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
2021-02-03 20:30:30 +00:00
Georges Basile Stavracas Neto
26c5434222 workspacesView: Use side-by-side layout
Currently, WorkspacesView positions each workspace on a
per-page layout, each page with the allocated width and
height of WorkspaceView. This layout doesn't work well
with horizontal workspaces.

Layout workspaces side by side, instead of per page. The
layout is influenced by a "fit mode", which reflects the
different behaviors exposed in the mockup. This fit mode
represents whether a single or all workspaces will fit
available geometry.

The single fit mode is always used for now. Next commits
will make it switch to the all fit mode when in the app
grid state.

The translation_{x,y} also needed to reflect the switch to
a side-by-side layout, and use the geometry of the workspaces
to determine the offset. Notice that, when the fit mode is ALL,
there's no translation applied.

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
Florian Müllner
0f1b566918 js: Use gjs-defined GObject accessors where possible
Nowadays gjs allows to omit get/set accessors for read-write properties,
and will define reasonable defaults in that case. In many cases we don't
need anything more than the default handling, let gjs handle those props.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
a41e294e21 workspaceThumbnails: Remove obsolete property
Since commit f55ff01239, the property has been replaced by
an adjustment.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
0064412359 appDisplay: Remove obsolete property
Since commit f09fbb19c, all app grids use pagination and the old
property is meaningless.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
3ff71ac40e iconGrid: Use correct default values in pspecs
The defaults are set in the code right now, but this is about to change.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
a9cbbd8017 pageIndicators: Remove animated indicators
Nothing uses them anymore, so clean out the code.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1629>
2021-02-03 09:55:29 +01:00
Georges Basile Stavracas Neto
5c7436be3e appDisplay: Never use animated indicators
The app grid itself now is horizontal, and is displayed beneath
workspaces, above the dash. This makes the indicator animations
out of place, as they're not coming from the edge anymore.

Use PageIndicators for both FolderView and AppDisplay.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1629>
2021-02-03 09:55:14 +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
Alexander Mikhaylenko
9ce666ac13 workspaceAnimation: Move background to WorkspaceGroup
Make each wallpaper have a wallpaper and clip it. Add a separate background
to MonitorGroup and add spacing between each workspace

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3635,
      https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/945,
      https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/948

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
ae4dab761e workspaceAnimation: Disable unredirection during the gesture
Make sure fullscreen apps can't block the animation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
bca654851c workspaceAnimation: Support multiple screens
Currently, there's one animation for the whole canvas. While it looks fine
with just one screen, it causes windows to move between screens when
switching workspaces. Instead, have a separate animation on each screen,
and sync their progress so that at any given time the progress "fraction"
is the same between all screens. Clip all animations to their screens so
that the windows don't leak to other screens.

If a window is placed between every screen, can end up in multiple
animations, in that case each part is still animated separately.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
8eba759932 workspaceAnimation: Group sticky windows and moving window
Since the transitions consists of window clones now, all the clones appear
above sticky windows. Clone sticky windows as well, and treat them same as
moving window instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
ee5564015a workspaceAnimation: Use a workspace strip
Currently, the workspace swipe transition only has one workspace in each
direction. This works until you try to do multiple swipes in quick
succession. The second swipe would continue the existing transition, which
only has 2 or 3 workspaces in it, and will hit a wall.

To prevent this, take all workspaces and arrange them into a column or row,
depending on the layout, and use that as a transition.

For the transition that happens when focusing a window on another workspace
(for example, via Alt+Tab), still use only two workspaces instead of all of
them.

Since we don't support layouts other than single rows/columns anymore,
diagonal transitions aren't supported anymore, and will be shown as
horizontal or vertical instead.

Since nw alt-tab and gesture transitions are different, don't allow to do
both at once, that is, disable swipe tracker when a programmatic transition
is going. This will also conveniently cancel a gesture transition if a
programmatic one is initiated while a gesture is in progress.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
9cf300c972 workspaceAnimation: Use window clones
Instead of reparenting windows, clone them. This will allow to properly
support multi-monitor setups in subsequent commits.

Block window mapping animation while the animation is running to prevent
new windows appearing during the animation from being visible at the same
time as their clones.

Fixes https://gitlab.gnome.org/GNOME/mutter/issues/929

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
0f99d46f87 workspaceAnimation: Add a background
In future we will need to use window clones to better support multiple
monitors. To avoid having to hide every window, show wallpapers behind
the workspace transition: one per monitor.

Put the wallpaper into a separate class right away, later it will be
useful to make the animation per-monitor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
2f78d32921 workspaceAnimation: Add to uiGroup insead of window_group
This will allow to hide window group completely in the following commits.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
e32ec73315 workspaceAnimation: Extract WorkspaceGroup
Simplify the code a bit. The workspace group is relatively self-contained,
so split it from the general animation. Reimplement _syncStacking().

This will help a lot later, with workspace strip and multi-monitor support.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
269c5ca957 workspaceAnimation: Stop depending on shellwm
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Alexander Mikhaylenko
bebd612a8f workspaceAnimation: Split from WindowManager
It's already too complex, and will get more complex in future, split it
out. Update the code style.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
2021-02-02 19:35:07 +00:00
Florian Müllner
42c2bf709e windowPreview: Overhaul chrome style
- increase close button size
 - use custom close icon that's better suited
   for the non-default 24pxp size
 - use translucent light gray for both close button
   and window caption

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-02 10:06:23 +01:00
Florian Müllner
30f27412c2 windowPreviews: Replace border with scale effect
We currently use a thick border to indicate the hovered/focused preview. It
works well for that purpose, but is a bit in the face. Slightly scaling up
the preview still provides a clear indication, but in a more subtle and
elegant way.

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
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
Florian Müllner
2bd91e738e workspace: Adjust spacing
Icons are always visible, so in order to not have overlays overlap
with other previews, we need to consider the sum of top- and border
oversizes rather than the maximum.

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
Florian Müllner
56c118de87 windowPreview: Keep borderCenter always visible
We need it to position the icon now, which isn't hidden with the
border.

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
Florian Müllner
efa3585bcc windowPreview: Add (back) application icons
The overview is less visually-busy nowadays, so add back application
icons to make identifying window previews easier.

Fun fact: Removing the icons was part of my very first gnome-shell
contribution!

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
Florian Müllner
5e10bed458 windowPreview: Allow titles to overlap other previews
We are about to add additional chrome, but still want to use
as much space as possible for the previews. Allowing titles
to overlap other previews should help keeping the additional
whitespace requirement low.

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
Florian Müllner
bc6849c7a2 windowPreview: Track overlay state separately
We currently express the state as a combination of border visibility
and the eventual transition state. That's tedious, in particular if
we want to use the state outside the show()/hide() methods.

Just track the requested visibility in a separate property.

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
Florian Müllner
de299f0a90 workspaceThumbnails: Center thumbnails in workspace navigator
We always request a natural width based on the maximum thumbnail scale,
but may very well use a smaller scale when allocating. This currently
results in thumbnails being off center, fix this by distributing any
extra space evenly before allocating thumbnails.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1620>
2021-02-01 16:34:37 +01:00
Guilherme Silva
779e66ae88 notificationDaemon: Fix icon-choosing logic
'image-data' (or 'image-path') should take precedence over 'app-icon',
even when both are sent by the application (e.g. Google Chrome).

Fixes #3616.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1616>
2021-02-01 13:58:20 +00:00
Jonas Dreßler
6ae49092c1 workspace: Use Util.lerp() instead of own _interpolate()
Use the utility function we newly introduced instead of having our own
private _interpolate() in workspace.js.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
959639bdc9 windowPreview: Cache the boundingBox of the layout manager
Accessing GObject properties from JS has proven to be quite slow because
of the JS->C->JS roundtrip involved. With the WindowPreview this
actually has an impact since we're accessing those properties very often
while creating new layouts.

So cache the boundingBox and the windowCenter properties of the
WindowPreview using a this._cachedBoundingBox JS object. This might
speed up opening the overview with lots of open windows significantly.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
a4bf44734d workspace: Don't store strategy on layout object
We're making the layout object fully owned by the layout strategy, so
store the current strategy somewhere else, that is as a private property
of the class.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
39e844ac0c workspace: Refactor layout scale and space calculation
Make computeScaleAndSpace() return an array including scale and space so
we no longer have to access the layout object from outside.

With this we also no longer need to set layout.space, since only the
scale property is needed in computeWindowSlots().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
8d9a92fe98 workspace: Make computeLayout() return a layout object
Start cleaning up the whole mess around the layout object a bit and
return a new object in the LayoutStrategies computeLayout()
implementation. This object is supposed to be opaque to the API user and
will only be passed to the layout strategy.

For now, keep setting a few things on that object from outside, we'll
clean that up later.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
ac7dc62da6 workspace: Move more things to LayoutStrategy subclass
Only keep computeLayout, computeWindowSlots, computeScaleAndSpace and
the contructor in the superclass, the rest is actually layout specific
and won't apply anymore when we introduce the new vertical layout
strategy.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Jonas Dreßler
c635ff490a workspace: Pass params object to LayoutStrategy
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Florian Müllner
add6dfe2e4 status/dwellClick: Remove menu arrow
This was missed in commit db9a008.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1618>
2021-02-01 11:40:03 +00:00
Abderrahim Kitouni
698e67c486 workspacesView: Fix scroll direction in RTL locales
Scrolling up or down (using the mouse wheel) should scroll to right
or left respectively (rather than the other way around).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1608>
2021-01-30 11:45:22 +00:00
Florian Müllner
151a104f9a dash: Only show separator when there are running apps
The separator is only really needed to distinguish favorite apps
from running apps, the show-apps button is distinct enough already.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1610>
2021-01-30 09:44:11 +00:00
Florian Müllner
9062d5dc78 workspace: Clip background
So that windows don't overflow the workspace background.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
2021-01-29 21:56:05 +00:00
Georges Basile Stavracas Neto
8eb81ae649 overview: Move background to Workspace
Move the background to the Workspace class by introducing a new container
called WorkspaceBackground, which handles clipping the background to the
workarea.

Move the click action from WorkspaceDisplay into each workspace.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
2021-01-29 21:56:05 +00:00
Georges Basile Stavracas Neto
cfc1f1fd9c background: Add option to not use background content size
Will be used by next commit to draw workspaces at a different size of the
background itself.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
2021-01-29 21:56:05 +00:00
Georges Basile Stavracas Neto
862b5be7a2 background: Trivial style cleanup
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
2021-01-29 21:56:05 +00:00
Florian Müllner
b84eb2437d workspaceThumbnails: Expand workspaces before scale-in animation
When the original animation was implemented, workspaces would only
ever be added at the end. We therefore got away with not having a
separate EXPANDING stage corresponding to the existing COLLAPSING
one when animating out.

Since support for creating in-between workspaces via DND was added,
this is no longer the case. And now that the thumbnails are centered,
the jump is quite noticeable.

Address this by adding new transitional states, so that we can
expand new thumbnails before scaling them in.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1609>
2021-01-29 17:55:44 +01: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
9db9445b0f workspaceThumbnail: Scale workspaces in and out
Make the slide property control the workspace scale, so that new workspaces
scale up, and destroyed workspaces scale down. The scale is done horizontally,
and only slightly vertically, as per design direction.

Rework the state tracking mechanism to remove the COLLAPSING state, since there's
no split between sliding out and collapsing anymore. Also remove the corresponding
'collapse-fraction' property from WorkspaceThumbnail.

Make ThumbnailsBox.vfunc_get_preferred_width() consider the slide-position property.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
df2181c913 workspaceThumbnail: Use current number of workspaces for sizes
There are situations where MetaWorkspaceManager and ThumbnailsBox disagree
on the number of workspaces, for example when animating them out. It's more
important to follow the visible number of workspaces while they're updated.

Make vfunc_get_preferred_width() and vfunc_get_preferred_height() use the
current number of workspace thumbnails to calculate their sizes, instead of
MetaWorkspaceManager's n-thumbnails property.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
d368bae503 workspaceThumbnail/thumbnailsBox: Set pivot point
Set the pivot point at the center of the ThumbnailsBox so that scaling
in and out looks better.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
451ba5b03a workspaceThumbnail: Remove wallpaper
They'll be replaced by a stylized background color to make them look
symbolic.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
0d4bce9fa7 workspaceThumbnail: Reduce maximum scale to 5%
As per design direction, reduce the maximum workspaces thumbnails to 5% of the
primary monitor size.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
9980c80619 workspaceThumbnail: Allocate final thumbnail sizes
ThumbnailsBox currently allocates each workspace thumbnail using their
porthole size, and scales them down using scale-x and scale-y. This is
slightly problematic since it doesn't allow for properly styling these
thumbnails through CSS.

Rework ThumbnailsBox to allocate workspace thumbnails at their actual
sizes, and scale down the '_contents' actor inside WorkspaceThumbnail.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00:00
Georges Basile Stavracas Neto
3ad7b85e25 workspaceThumbnail: Make it horizontal
Allocate workspace thumbnails horizontally. This requires introducing code
to handle the RTL direction. Do a small rewrite of the DnD hover method to
be simultaneously simpler and easier to follow, and work correctly on RTL.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
2021-01-29 15:01:03 +00: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