Commit Graph

8012 Commits

Author SHA1 Message Date
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
Marco Trevisan (Treviño)
a19e6573e1 loginDialog: Fill UserListItem layout to show the timed login indicator
When the timed indicator is shown the UserListItem layout should fill
so that the timed indicator can expand to use the whole item space.

So, always use the default value for x-align that will make it to fill
the available space without causing any regression when the timed
indicator is hidden.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3675
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1644>
2021-02-09 06:08:55 +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
Razze
aa392d45c9 fingerprint: Show different strings depending on type
Fprintd knows if the fingerprint reader is of the swipe or press type. We now show different labels depending on that.

Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2011

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1572>
2021-02-08 19:19:14 +00:00
Razze
824cdc9177 fingerprint: Use makeProxyWrapper for fprintManager
The reason this wasn't using the Gio.DBus.makeProxyWrapper() convenience API is that it passes custom flags to the proxy, and that wasn't supported by the wrapper at the time.

As this is now possible, this commit migrates us to the new API.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1572>
2021-02-08 19:19:14 +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
b0a48fad57 util: Add a GNOME version comparison function
Add a function that can compare GNOME versions, including the new naming
scheme for GNOME 40 and later.

Used in 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