Commit Graph

7871 Commits

Author SHA1 Message Date
Alexander Mikhaylenko
b156cabdc9 swipeTracker: Use unaccelerated deltas
Unaccelerated deltas make sure the gesture works the same regardless of how
fast the fingers move; this is what we were already doing for scrolling.

Remove the swipe multiplier as the deltas already match scrolling other than
the 1/10 multiplier Clutter applies to scrolling specifically.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1763>
2021-07-16 19:37:20 +00:00
Florian Müllner
20d99c69cb search: Exclude hidden results from keynav
Since commit 3fb02843, we no longer skip allocation for
results that don't fit the width, and give them a 0x0
allocation instead.

That has the unintended side effect of those children now
being available to keynav. There are cases where we want
0-sized actors to be part of the focus chain (e.g. FocusTrap),
but this isn't one of them, so explicitly exclude 0-sized
children from keynav.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1916>
2021-07-15 19:15:36 +02:00
Florian Müllner
6995c2fa9f shellInfo: Don't destroy source on undo
Destroying the source from an action callback will result in the
notification being destroyed twice:

 - source.destroy() destroys all its notifications

 - a notification destroys itself after an action
   was activated

This results in unwanted log spam when attempting to dispose the
notification for a second time.

There is actually no good reason for destroying the source explicitly,
as sources already self-destruct with their last notification.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
2021-07-13 12:38:51 +00:00
Florian Müllner
1f4eea12a5 messageTray: Always remove destroyed banners
Currently we only mark the banner as removed if it is destroyed
while in SHOWN or SHOWING state, but not if we're already HIDING
(for example in response to `NotificationBanner::done-displaying`).

If this happens, we'll try to destroy the notification again at
the end of the transition, which leads to (harmless but annoying)
log spam since Notifications were turned into GObjects (that are
disposed when destroyed).

Address this by always marking destroyed banners as removed, while
still only triggering a state update while shown (or in the process
of being shown).

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1908>
2021-07-13 12:38:51 +00:00
Florian Müllner
dc1aec5673 overviewControls: Fix warning on shutdown
ClutterActor unsets its layout manager's :container property during
dispose, so the corresponding vfunc should handle being passed NULL.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1909>
2021-07-08 23:17:01 +00:00
Florian Müllner
30e49cc3ca iconGrid: Disconnect signals on destroy
Otherwise the handler will trip over unset properties on an object
that is being disposed. Avoid the resulting log spam by disconnecting
the handler in question.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1909>
2021-07-08 23:17:01 +00:00
Florian Müllner
f51fb4bed0 ibusCandidatePopup: Use plain actor as dummy cursor
Now that source actors no longer have to be widgets, we can use
a plain actor for the dummy cursor and save a bit of overhead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1903>
2021-06-29 22:47:58 +02:00
Florian Müllner
16d3718735 boxpointer: Handle non-widget source actors
There is no convincing reason why source actors must be widgets,
so lift that restriction.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1903>
2021-06-29 22:47:50 +02:00
Lee
006d206f98 Magnifier: Filter caret tracking in gnome magnifier
Add a check to filter out caret tracking events that result in a caret
location of 0,0.

Fixes #4177

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1823>
2021-06-28 21:28:10 +00:00
Florian Müllner
8430aa59da status/power: Always sync after creating proxy
Otherwise the menu remains in an inconsistent state in case of an
error, until something else triggers a call to _sync() (like a
settings change).

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1901>
2021-06-28 20:49:43 +00:00
Florian Müllner
9e9ed42263 status/power: Update to new coding style
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4431

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1901>
2021-06-28 20:49:43 +00:00
Carlos Garnacho
c449058d44 magnifier: Remove needless actor
For the pointer clone, we actually have 2 actors (one that contains
the sprite, another that moves around). These can just be the same.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1902>
2021-06-28 20:53:57 +02:00
Carlos Garnacho
3df4b5ec7c magnifier: Add method to enable/disable crosshairs
These do some some signals connection and monitor layout tracking
that we forget to disconnect when the magnifier is disconnected.
This causes warnings if enabling the magnifier, disabling it,
switching to another tty, and back. (Presumably also happens for
monitor hotplugs).

This signal should just stay connected as long as it's needed,
so add a setEnabled() method on the CrossHairs actor that we
can hook on the magnifier.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1902>
2021-06-28 20:53:36 +02:00
Carlos Garnacho
a363f1343a magnifier: Unset variable holding GSource ID
Otherwise we try to remove the no longer existing GSource
later on.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1902>
2021-06-28 19:54:07 +02:00
Florian Müllner
54a71944ba boxpointer: Disable unredirection while visible
Some popovers like the ibus candidate popover may be requested while
showing an unredirected fullscreen window. Disable unredirection
while the popover is visible so that it can actually be shown.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1900>
2021-06-28 12:07:12 +02:00
Florian Müllner
158920924d shellDBus: Properly return from D-Bus methods
When implementing a D-Bus method synchronously, regular JS methods are
used. That is, whatever the method returns is passed as return value
to the method invocation.

However for asynchronous implementations, we need to explicitly return
a value to the invocation, otherwise the caller will wait until it times
out eventually.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
2021-06-17 21:03:58 +00:00
Florian Müllner
6813e246cd shellDBus: Remove bogus return statements
g_dbus_method_invocation_return_value() doesn't have a return value.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
2021-06-17 21:03:58 +00:00
Florian Müllner
c90fb27a2f shellDBus: Fix FocusApp()
The appDisplay used to be accessible via the viewSelector, but
that is gone now. Commit c09c070b15 adjusted the code, but the
replacement uses a Main.overview.appDisplay accessor that never
existed, whoops.

Fix this by exposing a new selectApp() method directly on the
overview, so we don't have to shuffle the appDisplay through
controls → overviewActor → overview.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1891>
2021-06-17 21:03:58 +00:00
Olivier Fourdan
8be5d33611 windowManager: Remove timeout on starting X11 services
With Xwayland started on demand, mutter/gnome-shell will spawn Xwayland
and GNOME settings daemon Xsettings.

Currently, gnome-shell uses a timeout of 5 seconds before canceling the
launch and declare failure to start X11 services.

While 5 seconds may seem like a lot of time, when this is executed on a
virtual machine part of a QA tests under load, this causes random
failures.

There is no good value here, we could increase the timeout but it will
always remain racy. Instead, remove the timeout, systemd itself already
has a timeout mechanism (with a much longer wait time).

Thanks to Benjamin Berg <bberg@redhat.com> for finding the root cause
and suggesting the fix.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1888>
2021-06-15 11:24:59 +02:00
Chris Mayo
8d042459ee lookingGlass: Use symbolic icons on the toolbar
Replace gtk-color-picker, a private GTK 3 icon, with
find-location-symbolic as used in GTK Inspector.

As suggested by Daniel van Vugt.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1671>
2021-06-14 18:51:30 +00:00
Harshad Gavali
177b36f82b overviewControls: Avoid hiding early AppDisplay when transitioning to Session
When transitioning from AppDisplay to Session,
AppDisplay should be visible throughout the transition.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1886>
2021-06-13 00:51:35 +02:00
Florian Müllner
5be67eb190 lookingGlass: Only pop modal after the transition
Right now we pop the modal immediately when closing, so the key-release
event of the Escape key ends up in the focus window which may consume it
for leaving fullscreen mode or similar.

We can avoid that in many cases by keeping the modal grab until the end
of the transition, as the key-release event will then likely occur while
the grab is still in place (provided animations are enabled).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1880>
2021-06-10 00:18:00 +00:00
Daniel van Vugt
1879ca741e lookingGlass: Avoid a little bit of RedBorderEffect overdraw
The left edge of the box was redrawing the bottom left corner when
the bottom edge had already done so.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1876>
2021-06-09 16:31:19 +00:00
Daniel van Vugt
d8802aafc4 lookingGlass: Paint the RedBorderEffect right edge the correct height
It was being painted one box thickness (`width`) too tall so you could
see a rendering glitch below the bottom right corner until now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1876>
2021-06-09 16:31:19 +00:00
Georges Basile Stavracas Neto
40543bdd28 portal: Own org.gnome.Shell.Portal for the access portal
org.freedesktop.impl.portal.desktop.gnome will be used for the
GNOME implementation of desktop portals in the future, so make
sure GNOME Shell's implementation of the access portal won't
conflict.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1872>
2021-06-05 21:29:52 -03:00
Georges Basile Stavracas Neto
5339b1e6a2 dnd: Immediately start drag done by pointer devices
Unlike touch screens, pointer devices (e.g. cursor, touchpad) are
basically never used to switch app grid pages, which is the main
use case for the drag threshold. This point was recently raised
as design feedback.

Immediately start drags when using pointer devices.

See https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3802#note_1124701

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
2021-05-31 10:59:11 -03:00
Georges Basile Stavracas Neto
e89c6179af dnd: Factor out calculation into a variable
Another trivial cleanup. This is in preparation for next commit, that
will expand on this if clause, and will make it a bit more complicated.
Using a variable here makes it easier to read.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
2021-05-30 21:32:54 -03:00
Georges Basile Stavracas Neto
88fa02147e dnd: Return Clutter.EVENT_STOP instead of true
Trivial cleanup.

Clutter.EVENT_STOP is more semantic, and this 'true' is inconsistent
with the 'return Clutter.EVENT_PROPAGATE;' a few lines above.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1866>
2021-05-30 21:27:51 -03:00
Georges Basile Stavracas Neto
dfae3281b9 workspaceAnimation: Allow long swipes in session
As per design feedback, allow long swipes in the session too.

See https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3802#note_1124701

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1865>
2021-05-30 12:02:12 -03:00
Georges Basile Stavracas Neto
e9119c625d workspaceThumbnail: Destroy thumbnails on destruction
Often, when using multiple monitors, the thumbnails box may be
destroyed before the 'hidden' signal of the Overview is emitted,
which leaves a bunch of lingering signal connections to the
workspace manager.

Call this._destroyThumbnails() in the _onDestroy handler, which
disconnects from workspace manager. This fixes the some of the log
spam that GNOME Shell produces with backtraces of destroyed actors.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1860>
2021-05-25 12:43:32 -03:00
Olivier Fourdan
d9239e2cee windowManager: Ignore error without systemd
On systems/setups not using systemd, a failure to start gsd-xsettings
with NOT_SUPPORTED does not denote a failure to start Xwayland, just
that we're not using systemd.

In that case, we should just ignore the error, otherwise it will prevent
Xwayland to start on such systems/setups without systemd.

Thanks to Rose Kunkel (@rosekunkel) for spotting the issue/suggesting
the fix.

Fixes: 019229c40e - windowManager: Return failure to start X11 services
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4284
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1850>
2021-05-18 14:31:28 +00:00
Jonas Ådahl
08fb067d24 js: Get idle monitor from backend
Its ownership has moved from dangeling to owned by the backend, which
has reflected the API is accessible by. Adapt to this change.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1838>
2021-05-18 13:42:52 +00:00
Georges Basile Stavracas Neto
0ed1a363a3 workspacesView: Queue relayout when overview adjustment value change
The overview adjustment quite significantly impacts the layout of
SecondaryMonitorDisplay(), and this needs to be accounted for by queueing
a relayout.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1845>
2021-05-12 18:08:55 +00:00
Georges Basile Stavracas Neto
81210f5846 workspacesView: Don't update secondary monitor thumbnails box if hidden
And save quite a few C/JS trampolines. Since the thumbnails box may not
have up-to-date properties, call _updateThumbnailParams() right after
showing the thumbnails box.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1845>
2021-05-12 18:08:55 +00:00
Georges Basile Stavracas Neto
a63c44ba2c workspacesView: Increase secondary monitor workspace scale
The current value, 70%, may end up leaving too much unused space on
secondary monitors. The new value of 80% is completely based on trial
and error, but seems to work slightly better.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1845>
2021-05-12 18:08:55 +00:00
Florian Müllner
803b944ffd appDisplay: Add :gesture-modes property
Both the main app grid and folders got a swipe tracker, which is
active in both OVERVIEW and POPUP mode. The result is that two
trackers fight over the same events, and everybody loses.

Address this by adding a :gesture-modes property that determines
the allowed modes for the associated swipe tracker.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1844>
2021-05-12 01:02:19 +02:00
Carlos Garnacho
6fc93b78bc appDisplay: Improve app grid interaction for touch devices
Currently, handling of touch devices in the app grid is a bit awkward,
paging by dragging the view can only happen if started from the gaps
between icons, trying to drag from an icon will trigger DnD, and popping
up the menu takes over it all.

Instead, have the app grid actions play this game of rock-paper-scissors:
- Fast swipes on icons trigger scrolling, beats DnD and menu
- Slower press-and-drag on icons trigger DnD, beats scrolling and menu
- Long press triggers menu, beats scrolling, is beaten by DnD

This allows quick swipes to handle navigation, while still allowing the
fine grained operations. DnD, when triggered, dismisses the menu, if
shown.

This all could probably be nicer with a more stateful gesture framework,
we're not there yet though.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3849
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
2021-05-11 16:13:49 +00:00
Carlos Garnacho
91a7978711 grabHelper: Propagate events while this._ignoreUntilRelease
Let these events to be handled as usual, so that the grabbing actor
can handle input differently (e.g. trigger DnD) while the grabHelper
is active.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
2021-05-11 16:13:49 +00:00
Carlos Garnacho
ecead8c727 dnd: Add timeoutThreshold setting
This setting (by default, 0) sets a time threshold in order to allow
DnD. If the drag is shorter than this threshold, DnD will be cancelled,
and event handling left to the next handlers.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
2021-05-11 16:13:49 +00:00
Sebastian Keller
0a7507c617 altTab: Avoid allocation cycle when showing CyclerHighlight
CyclerHighlight was showing and resizing one of its child widgets when
its own allocation was changed, queuing another relayout, resulting in
allocation cycle warnings. Avoid this by updating the size of the
highlight when the frame rect of window has changes rather than the size
of the CyclerHighlight actor itself.

Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4167
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1842>
2021-05-11 17:36:29 +02:00
Leleat
5423179844 switcherPopups: Correct selection with arrows and scrolling using RTL
The switcherPopups use _next() and _previous() to get the items
in the text direction. I. e. with LTR _next() gets the right item;
on RTL it gets the left item. This doesn't work well with RTL when using
the arrow keys since the text direction doesn't matter in those cases.
Pressing Left Arrow should still move left regardless of text direction.
So use the opposite methods.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1835>
2021-05-11 14:09:33 +00:00
Olivier Fourdan
019229c40e windowManager: Return failure to start X11 services
If for some reason the xserver failed to start, mutter/gnome-shell
should not attempt to connect to the X11 display otherwise it will
lock up in XCB.

An indication of such a premature failure of the xserver is when the X11
services fail to start.

Return the status so that the caller can cancel the connection in time
and avoid the lockup of mutter/gnome-shell in case of failure.

This, however, makes the X11 services a critical component to start
Xwayland, meaning that a failure to start those services for any other
reason than the xserver failing to start would still prevent Xwayland
and therefore X11 clients to run in Wayland. This is however a lesser
issue than mutter/gnome-shell locking up.

This basically reverts commit a96753f0 - "windowManager: X11 can work
without gsd-xsettings".

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1837>
2021-05-11 14:05:40 +00:00
Florian Müllner
0ccdb4746f appDisplay: Extend faded edges beyond fade area
Now that the fade effect was reverted to the old behavior by default,
the app grid must opt-in extend faded edges beyond the regular fade
area.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1831>
2021-05-11 13:21:40 +00:00
Nishal Kulkarni
2b2a71832a windowManager: Hide overview on using hotkey
Change behavior on pressing Super+Number in Activities/Overview mode
so that the overview mode is hidden and application can be used.

This makes it consistent with clicking icon in the dash.

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1771>
2021-05-11 02:36:54 +02:00
Jonas Dreßler
954131c1c8 overview: Sync grabs after running startup animation
In the nested session the startup animation sometimes fails, weirdly
that always happens to me when running a freshly built gnome-shell the
first time. The reason it fails is that mutter fails to aquire a pointer
grab from the xserver, XIGrabDevice() is unsuccessful.

A simple workaround for this race condition in the xserver is to just
grab the devices a bit later, that is after the startups animation
instead of before it.

This was also tested with disabled animations, and seems to work just as
well in that case.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1812>
2021-05-04 16:18:30 +00:00
Sebastian Keller
e7780623fe dnd: Don't use transformed size to calculate parent scale when restoring
Some drag actor parents might change their width to 0 after the drag
actor has been removed. If the drag is now canceled and the drag actor
is animated to return to the current parent position and scale, this
scale can not be determined and falls back to 1.0. This might be wrong
and can result in the drag actor being too large/small at the end of the
return animation.

To avoid this calculate the scale of the parent by recursively
calculating the product of its parents individual scales.

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

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

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

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

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

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

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
2021-05-04 14:16:46 +00:00
Jonas Dreßler
7f90a46f8c workspacesView: Clip the SecondaryMonitorDisplay instead of the view
Make the SecondaryMonitorDisplay a bit more similar to the
ControlsManager container on the primary monitor, and clip that widget
instead of the WorkspacesViews on secondary monitors.

This will allow us to overpaint the WorkspacesView allocation and paint
the WindowPreview overlays like the title and close button outside the
allocation with the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
2021-05-04 14:16:46 +00:00
Sebastian Keller
79acae4176 dnd: Don't try to restore to parent location if parent got destroyed
The original parent of a dragged actor might have been destroyed after
the drag has been started. When the drag is canceled and _dragOrigParent
is set, the code is trying to get the current position and size of it
when restoring. With a destroyed parent this however would result in a
crash.

This could happen for example when starting a drag on a window preview
while the overview is hiding and then releasing it once the transition
is done.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1817>
2021-04-29 18:25:56 +00:00
Sebastian Keller
0e917c3dbf workspaceThumbnail: Only create thumbnails once
`ThumbnailsBox` listens for the `showing` signal from the `Overview` to
create its thumbnails and destroys them on the `hide` signal. Since the
`showing` signal can be emitted multiple times when switching between
the shown and hidden state without ever fully completing the transition,
this will cause `_createThumbnails` to be called multiple times, each
time adding another set of workspaces.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
2021-04-29 17:58:45 +00:00
Sebastian Keller
77023135ac overviewControls: Stop transitions when starting a gesture
When starting a gesture to open the overview while a transition to hide
the overview is running, Overview._shown will be first set to false when
starting the transition and then to true by the gesture before the
`onComplete` callback is called. The `onComplete` callback in this case
is `Overview._hideDone()` which starts a transition to show the overview
again which also emits the `showing` signal. Since the gesture emits a
`showing` signal as well, this results in two consecutive `showing`
signals without a `hiding` signal in between.

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

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4004
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
2021-04-29 17:58:45 +00:00
Leleat
fd0da9606f appMenu: Only show Open Windows, if there are at least 2 windows
It doesn't make sense to show the 'Open Windows' in the app menu,
if the app only has 1 open window to switch between. Hide the
window section in that case.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1827>
2021-04-29 12:22:38 +02:00
Sebastian Keller
401b584384 appDisplay: Don't use symbolic icon at full size for system actions
When attempting to account for scaling in e65e5ede the icon_size of the
StIcon was set to the target size, overriding the icon-size set in the
'system-action-icon' CSS, which was only half the size. The intent of
that commit however was not to scale up the symbolic icon, but the
circle around it. Do this by manually applying the scaling factor.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1777>
2021-04-29 09:42:40 +00:00
Leleat
4e35ca8e26 windowPreview: Make St.Label use single line mode
When a windowPreview is hovered or selected, it will show its window's
title as a caption. That title may contain Newline characters which will
effect the windowPreview size. Make the caption's St.Label use single
line mode to prevent that.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1822>
2021-04-28 14:29:19 +02:00
Sebastian Keller
380d61dc43 screenshot: Ignore events in SelectArea after making a selection
The grab and actor are only removed after the selection rectangle has
finished fading out. During this time it was possible to still change
the position of the selection rectangle.

Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2761
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1825>
2021-04-28 11:40:19 +00:00
Sebastian Keller
548e18ad7e screenshot: Only select area on button release after a button down
On Wayland it is possible to trigger area selection with a button
already being down. SelectArea would then react to the subsequent button
release without ever having seen a corresponding button down first,
leaving the start coordinates of the selection rectangle uninitialized.

Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2761
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1825>
2021-04-28 11:40:19 +00:00
Carlos Garnacho
82c2f293a0 keyboard: Always emit ::pressed late on keys with variants
When we press a key with variants, we used to prevent an
early ::pressed, because a long press could show the options
popover, and the press be undone.

In addition, this long press could move to one of the suboptions,
and be released there. For this case we also want this late
emission of the ::pressed signal.

This makes the "tap, drag, release" pattern work on the
regular OSK keys, in addition to the emoji panel.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
2021-04-27 22:02:53 +02:00
Carlos Garnacho
40e53492ab keyboard: Allow calling _release() without press on OSK keys with touch
This is already allowed for pointer events, but touch events still expected
that the touch begin and end happen on the same Key actor. Change this
behavior for touch events, this is necessary for the tap-drag-release
pattern to select key variants to work on all input devices.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
2021-04-27 21:58:24 +02:00
Prajna Sariputra
6ee2c4f74c status/power: Always show real percentage in battery label
We currently display the percentage as "100%" if the battery state is
"fully charged", but the actual capacity may be lower than that.

Just show the real percentage, which is consistent with Settings.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1787>
2021-04-27 21:04:34 +02:00
Sebastian Keller
b93bf2bd69 altTab: Avoid setting GObject property to undefined instead of null
The windowActor in the CyclerHighlight was set to undefined if
this._window was null. This was causing an error when trying to set it
as a property.

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

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

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1811>
2021-04-19 20:24:54 +00:00
Florian Müllner
d823141360 dialog: Ensure action callback is called with no arguments
Using the callback directly as signal handler means that it will
receive the signal parameters (in this case: the StButton instance
that emits the signal).

This leaks an implementation detail that is harmless in the best
case, but can break dialogs when using bind() on the callback.

Avoid that trap by explicitly calling the callback without arguments.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
2021-04-19 19:12:59 +02:00
Florian Müllner
7eba5322b5 audioDeviceSelection: Ensure close() is called with no arguments
This is the same as commit c5b18ee66a, but for the audio device selection
dialog.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
2021-04-19 19:12:59 +02:00
Florian Müllner
7935da6168 audioDeviceSelection: Move a method to the new coding style ...
... before touching its code in the next commit.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
2021-04-19 19:12:59 +02:00
Alexander Mikhaylenko
58ed969dd1 background: Check xml mime type instead of extension
This is required to be able to set animated wallpapers with the wallpaper
portal, which names them 'background' without an extension.

See https://gitlab.gnome.org/bertob/nostalgia/-/merge_requests/12

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

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

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

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1810>
2021-04-14 15:43:09 +00:00
Jia Chao
f76e6877c7 keyboard: Fix suggestions box
The suggestions box actor was not being correctly populated.
Make it correctly use the St.BoxLayout add_child() method.

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1805>
2021-04-12 12:06:30 -03:00
Florian Müllner
dd7d336228 workspacesView: Don't tie PgUp/PgDown to mapped state
Both app grid and window picker are now always visible in the overview,
so their handling of the PgUp/PgDown keys conflicts.

Resolve that by checking for the overview state instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1798>
2021-04-08 20:48:58 +02:00
Florian Müllner
fc54e0bed8 workspacesView: Fix PgUp/PgDown shortcut
We still try to switch to the workspace above/below, which doesn't
do anything since the layout is now horizontal.

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

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

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1670>
2021-04-08 17:51:15 +00:00
Sebastian Keller
6f0589313d appDisplay: Ensure icon grid is always aligned with the pixel grid
When adaptToSize was called with an odd width, the calculated padding
was not an integer and as a result the icon grid was no longer aligned
to the pixel grid. Similarly it was possible for the page size to be a
non-integer value, which was causing items to not be aligned for
pages > 1.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1799>
2021-04-08 16:50:46 +00:00
Florian Müllner
e6be180df1 main: Use session mode property for welcome dialog
We only want to show the welcome dialog in the user session, not
on the login screen or during initial setup. We currently achieve
that by explicitly checking for those mode names, but there are
other modes like gnome-classic where the dialog is equally un-
helpful. Support those cases by adding a session mode property
that determines whether the welcome dialog should be enabled,
so that modes can opt in or out of the feature themselves.

(Both the 'gdm' and 'initial-setup' modes are based on the
'restricted' mode, so this change does not affect them)

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1793>
2021-04-06 18:57:39 +00:00
Zander Brown
2f70e524c3 remoteSearch: Fetch enabled/disabled list once
GLib should be caching the values but it seems unnecessary to fetch
and marshal what should be the same lists N times instead of just once

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1791>
2021-04-02 19:07:56 +00:00
Suryashankar Das
4bfb91c5cd overview: Pass state while calling _animateVisible()
Pass OverviewControls.ControlsState.WINDOW_PICKER to the _animateVisible
function in _hideDone().

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3876
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1769>
2021-04-02 10:20:32 +00:00
Carlos Garnacho
a7a7ea4af7 appDisplay: Save pages after drag end
In the case that we drop an app in the dash, we take the icon
out of its current page, but we forget to save the page after
that.

This results in oddities dragging further elements around, as
the PageManager does no longer consider them to be in the
positions they actually are.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1939984
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1775>
2021-03-31 10:35:26 +00:00
Sebastian Keller
dfc44973de status/network: Disconnect signal handler on destroy in NMConnectionItem
Otherwise this can trigger _sync() calls after the objects it is trying
to update have been destroyed.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1782>
2021-03-31 10:31:12 +00:00
Yuri Konotopov
02b06385ea extensionDownloader: Use POST request for checking updates
Usage of GET requests for checking updates was made deprecated
at website some time ago [1], but REST endpoint was
CSRF-protected until recently [2].
The body of update request may be big enough and thus does not
suitable for GET requests.

[1] 0b38da1b2b
[2] e3ab0c07dc

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1781>
2021-03-31 13:31:00 +04:00
Peng Wu
f563424417 keyboard: Fix display keyboard layout crash with some input methods
Some ibus input method will use the current keyboard layout,
and return "default" as the keyboard layout.
When this happens, display the current keyboard layout instead.

Fixes #3863.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1756>
2021-03-29 09:33:45 +00:00
Daniel van Vugt
1f0e4b58ab keyboard: Handle symbolic OSK key codes as explicitly invalid
`key` is an empty string in this case, causing `charCodeAt(0)` to return
`NaN`, which when passed to `Clutter.unicode_to_keysym` now generates an
error in gjs >= 1.67.3:

```
JS ERROR: Error: Argument wc: value is out of range for uint32
```

And the symbolic keys like Backspace, Enter and Caps Lock would have their
presses ignored.

Just skip the call to `charCodeAt` that will fail and allow
`Clutter.unicode_to_keysym` to return its usual error flag.

Fixes: https://bugs.launchpad.net/bugs/1918738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1758>
2021-03-15 12:41:10 +00:00
Daniel van Vugt
c5b18ee66a status/network: Ensure the Cancel button passes undefined to close()
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:

```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```

And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.

Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.

Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
2021-03-15 18:19:04 +08:00
Sebastian Keller
f2db9b52c9 iconGrid: Only use page relative coords for orientation in getDropTarget
The x and y coordinates were both adjusted to be page relative, even
though the icon grid can only scroll in one direction. This was leading
to coordinates outside of the icon grid to be considered part of it and
a wrong drop target to be chosen.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1767>
2021-03-14 18:44:03 +00:00
Florian Müllner
3c221cea48 overview: Fix showApps() compatibility method
The method is unused in gnome-shell itself, but extensions may still
want to call it, so make sure it actually works.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1766>
2021-03-14 12:47:42 +00:00
Florian Müllner
d271a51bfd swipeTracker: Remove unused property
The :allow-long-swipes GObject property relies on the automatic
getter/setter added by gjs and is not actually backed by
_allowLongSwipes.

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

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

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

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

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
9152d6613b workspacesView: Store some variables outside the children-allocate loop
We've seen this to help quite a bit with performance previously, so also
do it here.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
d21a0b186e iconGrid: Subclass a C actor for BaseIcon
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
2021-03-13 22:13:25 +00:00
Jonas Dreßler
36b103525c keyboard: Correctly compare cursor rect to keyboard rect
The logic that decides whether we should shift the window up when the
cursor rectangle overlaps with the keyboard rectangle doesn't work
properly right now, we want it to work like this:

- If the currently focused window is shifted up, keep it shifted up
until the cursor rect no longer overlaps the keyboard rect. To do that
comparison correctly, we need to adjust for the height the cursor rect
is shifted up by (keyboardHeight) and temporarily shift it down again.

- If the currently focused is not shifted up, we want to shift it up as
soon as the focus rect overlaps the keyboard rect. If that's not the
case, want still want to call _setFocusWindow(null) in order to shift
the previously focused window back down.

This fixes two issues: 1) We're currently shifting windows back down at
the wrong position of the cursor (that is y < keyboardHeight). 2) We're
not shifting down previously focused windows when focusing a different
window with the new focus in a specific region (y >= keyboardHeight &&
y + h < monitor.y + monitor.height - keyboardHeight).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
95ed7c7a06 keyboard: Add proper tracking of window movements to focus tracker
So far the FocusTracker of the OSK can only recognize grab ops on a
window, that is when the user grabs the window using a mouse or the
touchscreen and actively drags it somewhere.

Window can also be moved using keyboard shortcuts, fullscreen buttons or
other ways which don't rely on grabs. Start also supporting those window
movements by listening to the "position-changed" signal on the currently
focused window and emitting the new "window-moved" signal in that case.

Because the OSK sometimes moves windows by itself, we temporarily
disconnect from that new signal while we move the focused window in
_windowSlideAnimationComplete().

This also takes care of resetting this._focusWindowStartY on movements
of the window.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
7b990daee2 keyboard: Animate focus window using position instead of translation-y
Commit 8526776b4a changed the OSK to use
the translation-y property of the MetaWindowActor when animating a focus
window, which broke two things:

1) It's not compatible with the obscured region culling we do for
windows in mutter. That's because MetaCullable strictly operates in
integer coordinates and thus has to ignore any transformations
(translation-y is a transformation). Because of this, during the
animation and gesture, window damage is now tracked incorrectly,
introducing painting issues. The best fix for this would probably be
factoring in transformations when tracking damage in MetaCullable, but
that's not feasible right now.

2) It broke the shifting up of maximized and tiled windows, likely that
is because they are positioned using constraints internally, and mutter
enforces those constraints every time meta_window_move_frame() is
called, not allowing the window to move somewhere else.

To fix both issues, go back to the old way of shifting the window for
now, using the fixed y position of the ClutterActor. To make sure the
drag-up gesture still works, store the initial y1 position of the window
and then use that as a reference point for all our animations.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
2cf8b93a7b keyboard: Allow closing immediately
Just like opening the OSK, make it possible to close it immediately,
we'll make use of this in the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Jonas Dreßler
95b83575cb keyboard: Don't move focusWindow back down on window grab
I suggested it myself when reviewing
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668, so
here I am reverting that again...

The difference between calling _setFocusWindow(null) and simply
unsetting the focusWindow is that the former animates the window back to
its position before we shifted it up, while the latter simply "lets go
of the window".

In this case we actually want the latter because after the user grabbed
the window, we obviously should not animate it away right underneath the
users pointer/finger.

To ensure the same mistake doesn't happen again, add a small comment
explaining why this code is as it is.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
2021-03-13 18:28:15 +00:00
Alexander Mikhaylenko
f48e58a81a swipeTracker: Reset before emitting 'end' and not after
If the actor is unmapped in the handler, the touch gesture will cancel.
Since we haven't reset the state yet, it will still work and will actually
cancel the gesture, so reset before that instead.

Fixes overview cancelling when trying to open it with a swipe.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
3c1074085e swipeTracker: Clamp position when long swipes are enabled too
Avoid wrapping back to the first page when swiping forward from the last
page.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
df4c05f834 swipeTracker: Pass orientation in constructor
When this class was written, all swipes in the shell were vertical, so it
made sense to make the default orientation vertical. This isn't the case
anymore, thus pass make it mandatory to specify orientation when creating
a tracker.

Change the property default values to horizontal as well to match Clutter
instead of the old shell design.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Alexander Mikhaylenko
c06bc74d6d swipeTracker: Check orientation with a threshold for touchpad
Avoid picking the direction too early.

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

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
2021-03-13 18:08:24 +00:00
Jonas Dreßler
b160e44dab keyboard: Stop offsetting the focus rectangle
The focus rectangle of the OSK currently gets stored with an offset that
removes the global coordinates and makes it window-local coordinates.
This offsetting has been applied since the introduction of the
FocusTracker with commit fc5ab44704 and it
seems there's no real reason for it.

By removing this, we also emit position-changed when the window has
moved but the window-local coordinates stayed the same. We really want
to emit position-changed in that case because it might affect whether
the window needs to be shifted up.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
746230f8b6 keyboard: Ignore focus rects outside the window
Apparently some clients, including gtk don't "clip" the focus rectangle
to their window bounds when scrolling the focus outside the window. This
makes us shift up windows when the focus actually is no longer visible.

This issue needs fixing in GTK, it should probably stop reporting
focus changes when the focus moves outside of the visible view. We can
still do a little bit better on our side though and "clip" the rectangle
to the windows frame rect: If it moves out of the window, we simply stop
updating our focus rect.

The intersection check introduces a small problem though: Some clients
(for example gedit) will give us a cursor rect that has a 0 width or
height. This won't play well with graphene_rect_intersect()
(GrapheneRects never intersect if they are 0-sized), so we set the size
to 1 in case we get a 0-sized rectangle.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
7c83cbe135 keyboard: Use GrapheneRect in focus tracker
This will be useful in the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
3acf840c99 keyboard: Initialize the FocusTrackers current window correctly
The FocusTracker keeps track of the currently focused window using its
internal this._currentWindow property. It will only pick up the focused
window though when receiving a "notify::focus-window" signal, so the
focused window that's set when the FocusTracker is created won't be
picked up.

Fix that by setting the _currentWindow during creation of the
FocusTracker.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
d8adeba6b6 keyboard: Properly destroy focus manager when destroying keyboard
We're currently leaking this object, so make sure to disconnect
everything properly and plug the leak.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
Jonas Dreßler
6f39d76a3e keyboard: Remove unused argument
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
2021-03-12 15:56:12 +00:00
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