Since touchpad smooth scroll events with source finger are handled by
the swipeTracker, the workspace scroll handler can focus on discrete
events.
Thanks to Mutter emulating discrete scroll events, see
meta_seat_impl_notify_scroll_continuous_in_impl in meta-seat-impl.c,
it is safe to ignore smooth scroll in the workspace scroll handler
and handle exclusively discrete events.
In addition, once high-resolution scroll events land in Mutter [1], a
mouse will be able generate non emulated smooth scroll events that
should be ignored in favour of the discrete scroll events.
Otherwise, a single mouse wheel click will scroll through multiple
workspaces at once.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1959>
The keyboard is placed outside of the screen when shown and then slides
in via a transition that changes the translate-y property. This
translation does not affect the allocation of the Keyboard actor and as
such does not trigger any of the signals LayoutManager is connected to
to update the input region. This means the input region remains at the
original position of the actor outside of the screen and as a result on
X11 clicks will go through to the underlying window.
There was a workaround for this by queuing a relayout at the end of the
transition, but this stopped working due to optimizations avoiding
unnecessary allocation changes.
This updates that workaround to toggle the visibility of the actor
instead, which is the other signal that LayoutManager reacts to. Once
ClutterActor provides better ways to react to transforms this can
hopefully be removed entirely.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1955>
Sometimes when an icon is dragged and dropped in Dash, one Favourite app icon
can appear to the right of Dash separator. This can happen when available system
resources are low and the PlaceHolder destroy animation is delayed and the
corresponding container child is still present. With this commit the separator
position is calculated correctly, even when the animation is pending.
Fixes#3966, #3799
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1804>
eee2ccac fixed window opacity being changed outside of transitions but
resulted in the final step of the transition, that would set the window
to fully opaque, being missed.
This change now moves the opacity change entirely out of allocation and
instead follows the adjustment changes directly, which still fixes the
original bug and ensures the opacity is also applied for the last step
in the transition.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4561
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1957>
GJS added a console module that extensions may start using. To ensure that
extensions using console.log() and similar functions don't show up as
'Gjs-Console' in users' system logs, we should call setConsoleLogdomain()
with 'GNOME Shell'.
This GJS API addition is only accessible using ECMAScript Modules (ESM),
this commit moves shell startup to a small init.js module and adapts
CI jobs to either handle or ignore it.
We can drop the .jscheckignore file when future versions of SpiderMonkey
allow for compile checks without validating module specifiers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1958>
!1940 added support for soup 3, including a fallback to soup 2.4
where the newer version isn't available.
Unfortunately it missed that libgweather has a hidden soup dependency,
and now gnome-shell fails to start if a weather location has been set
up and soup 3 is available.
We don't have a good way to detect that case, so hide the soup 3 support
behind a build option. Distributors are expected to switch it at the
same time as libgweather.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1966>
Unlike for the old Soup.SessionSync/SessionAsync classes,
Soup.Session:ssl-use-system-ca-file already defaults to true.
In Soup3, the behavior was made unconditional and the property
removed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Quoting the documentation:
In libsoup 2.44 and later, you can set the session's “proxy-resolver”
property to the resolver returned by g_proxy_resolver_get_default() to
get the same effect. Note that for "plain" SoupSessions (ie, not
SoupSessionAsync or SoupSessionSync), this is done for you automatically.
libsoup 2.44 was released in 2013, so we can safely assume that Soup is
new enough to handle this for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
The code that handles extracting extension archives currently uses
an awkward double-callback system. We can do significantly better
by using an async function and exceptions.
Partially based on code from Marco Trevisan.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Move all remaining bits to the new coding style before making
further changes.
The let → const changes are selectively done to the bits that'll
still be around at the end of the patch series.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Which better communicates what we are checking for, and is a little more
elegant than repeatedly writing:
```
Main.overview.animationInProgress && Main.overview.visibleTarget == false
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1440>
We hide our own "New Window" item if the app itself includes a
"new-window" action. That means that the separator between the
built-in item and desktop actions introduces a small inconsistency
depending on whether a "New Window" item is provided by the desktop
action or ourselves. There's no good reason for that from a user's
perspective, so remove the separator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The context menu in the overview includes actions for managing
favorites. Add those to the AppMenu class, but make it another
option as the actions would be slightly weird in the top bar menu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The top bar menu always corresponds to a running app, so it made
sense to include the 'Quit' item unconditionally. That won't be
the case for the overview context menus, so handle app state changes
and show/hide the item as necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
Since commit fd0da9606f, we only show the "Open Windows" section
if there are at least two windows. That's another subtle difference
with the overview context menus, but while limiting the section to
a minimum of two windows makes sense where the menu always represents
a running app, it is useful to show the section even for single windows
in the dash/app grid.
Account for both uses cases by adding a corresponding option to the
constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There's a subtle difference between the top bar menu and the app
icon context menus in the overview regarding the "Open Window"
section.
The former includes skip-taskbar windows, the latter doesn't. It
clearly doesn't make sense for the context menu to include windows
that aren't shown in the overview, but skip-taskbar windows are
likely also less useful in the top bar menu.
Just settle on the behavior of the context menus and move on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
This is the expected behavior when activating a window or app. Until
now we could rely on the menu being hidden in the overview, but as
that is about to change, make sure the menu behaves as expected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
App windows are ordered by recency, so a focus change (correctly)
triggers the ::window-changed signal. If we rebuild the section
immediately in response, the activating item will be destroyed
before the menu's ::activate handler, with the result that the
menu remains open.
Defer the section update in that case to allow the menu to process
the ::activate signal first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
For now the menu is only used in the top bar, where we can assume
that it exists "forever". This won't be the case when we start
reusing it elsewhere, so make sure we clean up after ourselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There was a potential issue when suspend was inhibited and immediately
uninhibited again before the creation of the inhibitor has finished.
Then the new inhibitor would be kept active.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
ScreenShield::_syncInhibitor() was closing (and recreating) the
inhibitor everytime it was called, even if no change was needed.
This gets called in various places, including on property changes in
the login1 dbus object. These happen by the time logind already started
suspending at which point new inhibitors can no longer be created. It is
only waiting for existing inhibitors to be closed, so closing the
inhibitor without a new inhibitor will cause the suspending to proceed
immediately if no other inhibitors are present. This can also happen
before the lock screen is shown, which will then complete after resume.
Fix this by keeping track of the expected inhibition state and only
create or close inhibitors if there was a change to that.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3736
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.
Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.
Instead, extensions have to use domain-specific versions
of the gettext functions:
```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```
Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2594
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.
This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137https://bugs.launchpad.net/bugs/1936643
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
The PointerWatcher passes the current pointer position to every watch,
so we don't have to query the pointer again scrollToMousePos() is used
as watch callback.
While that should be the only use, be conservative and still query the
pointer when called without arguments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1932>
Right now the Show Password menu is shown unconditionally for password
entries, ignoring the org.gnome.desktop.lockdown disable-show-password
key.
StShellEntry now honors that key for its peek icon, and there's little
reason for the peek icon and the menu to ever be out of sync.
This commit forces the menu and the icon to always be in sync, and
so makes the menu lock down work automatically, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
The behavior when switching workspaces now with the touchpad gesture is
very very weird, it almost always swipes to the last workspace instead
of the next one.
So revert this change again and only swipe a single page per gesture. We
can enable long swipes again when we've figured out a proper way to
detect what the user wants (which is going to be quite challenging), see
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4355.
This reverts commit dfae3281b9.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1933>
ClutterVirtualInputDevice::notify_keyval() expects time to be in
microseconds but Clutter::get_current_event_time() returns the time in
milliseconds. On Wayland the generated event triggers all the warnings
in MetaDisplay::sanity_check_timestamps() due to the event time
seemingly being in the past.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1926>
Dragging a window preview in the overview is supposed to change the
opacity of the dragged actor. This however fails for minimized windows,
because Workspace::allocate() also changes the opacity of those. The
allocation gets triggered by removing the window actor from the
workspace when starting the drag. Avoid this by only changing the
opacity during the overview transitions.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4292
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1847>
At the moment user switching functionality is controlled by two
settings:
org.gnome.desktop.lockdown disable-user-switching
for the panel when the session is unlocked, and
org.gnome.desktop.screensaver user-switch-enabled
for the unlock dialog when the session is locked.
Having the lockdown setting not apply when the screen is
locked is counterintuitive.
This commit makes the unlock dialog honor both settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1833>
Since this is a bin and not a button, and it doesn't have any click/keyboard
handling on its own (as in that case it needs a parent button wired like in
the messages list controls), it is confusing that it has can_focus set to
True. To avoid any confusion, this commit removes it without breaking anything
since it had no real use.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1920>
This one was moved to Meta.Context as well.
I don't know why the `debugexit` command quit with an error code
(it dates back all the way to commit 98bd590a5d). Terminating on
request by the user doesn't sound like an error, so don't replicate
that particular behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1917>
Before this, creating a separate instance of `Location.Indicator` failed
because it tries to create export the same DBus path.
This is useful for extensions adding panels on multiple monitors. But
it also seems like a cleaner design to separate the indicator widget
from the logically separate role as a Geoclue agent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1919>
We build controls layout using the whole monitor vertical space as
available, however extensions or external apps in X11 may reduce the
workarea size horizontally and the shell should always take care of it.
Given that we're already assuming that the allocation is monitor-based
and that we're adjusting it to the workarea, we can just make it more
explicit by using a workarea box that is used as the allocation area.
As per this, we also apply the same logic of applied to the vertical
dimension to the horizontal one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
To compute the available height for the layout we're currently using the
panel position, while this works for the current and default setup, the
shell may be configured to use a different workarea, so we should rely on
it to compute the available space, instead of a specific widget.
So get the current monitor index for the current view and use its coordinates
instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
The background group is currently allocated taking care of the workarea
x, y offset but not of its width/height and this may lead to building a
wrongly sized workspace view when the workarea size is not matching the
monitor size (like when there are struts set).
So, take care of the difference between the workarea and monitor
absolute end coordinates to allocate the background scaled content box.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892>
We currently disable all network items on both the lock- and login
screen. While it makes sense to be very restrictive on the lock screen,
there are some (fringe) use cases for being more permissive on the
login screen (like remote home directories only accessible via VPN).
There's precedence with the power-off/restart actions to be less
restrictive on the login screen, and since we started respecting
the `network-control` polkit action, it's possible to restore the
old behavior if desired.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
NetworkManager installs a `network-control` polkit action that can
be used to disallow network configuration, except that we happily
ignore it. Add it to the conditions that turn a network section
insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
Setting up a connection for an Enterprise WPA(2) encrypted wireless
network requires Settings. That's not available when windows are
disabled via the session mode, so filter out affected entries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
The item launches the corresponding Settings panel when activated, which
doesn't work when windows are disabled by the session mode. Rather than
failing silently, turn the item insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
If parsing the pipeline fails for some reason, we currently end up
with a zombie session that leads to a stuck recording indicator in
gnome-shell.
Instead, properly tear down the session to allow mutter and gnome-shell
to correctly update their state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1878>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The current gstreamer pipeline performs quite bad on slower machines and
is dropping lots of frames, improve the pipeline by changing a few
things:
- Use threads for videoconvert and improve speed of videoconvert by
disabling some unneeded things
- Add a queue before the encoding step, this allows the encoder to work
at its own pace and will lead to a lot more stability
- Remove the fixed quantizer and only set a max quantizer, this helps
quite a bit with performance
- Change the deadline parameter of vp8enc to 1: This makes the encoder
go into real time mode, which will make it a lot faster
- Set cpu-used to 16, the maximum possible value.
- Set static-threshold to 1000, static-threshold is the motion detection
threshold, and while a value of 100 is recommended for screencasting in
the gstreamer documentation (see [1]), using 1000 appears to perform a
lot better and still outputs fairly good quality
- Set a larger buffer size than the default size, this seems to get a
bit more stability during high load scenarios
All in all, those changes make the pipeline drop no more frames when
recording at 30 FPS and 2K screen resolution. That was tested on a
fairly recent mobile core-i5 processor.
Also, because we now have two %T replacement strings for the number of
threads, we need to switch to replaceAll(). For that to work, we have to
put the %T matching expression into quotes.
[1] https://gstreamer.freedesktop.org/documentation/vpx/GstVPXEnc.html?gi-language=c#GstVPXEnc:static-threshold
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1633>
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>
`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>
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>
For the screensaver service, it is quite normal that a consumer only
subscribes to the "ActiveChanged" signal without calling any methods.
The result is that we don't know about the consumer, and shut down
the service anyway after we hit the timeout.
If this happens, we break functionality like gnome-settings-daemon's
screen blanking on idle.
Fix this by simply disabling auto-shutdown for the service, which
also reflects the expectation that the screen saver service is
always running in a GNOME session.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4114
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1824>
It can happen that we get a problem report and a verification failure at
the same time. For fingerprint, a problem report can result in an
internal verification failure to be queued.
Remove this queued failure again if we got a failure already from GDM
directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment a failure in a background service can lead to the
various verification signals getting disconnected, even though
we still need them for a foreground service.
This commit changes the code to only disconnect when we've run
out of tries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment we set the state of the auth prompt to failed any
time the user fails an attempt. But verification is still going
on until the user exhausts all attempts, so that's wrong.
This commit changes it to only set the state to failed when the
user is out of tries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
At the moment we treat a failure in any service as a signal to stop
tracking users responses to service questions.
This commit makes sure we don't stop waiting for answers if a background
service fails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1821>
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>
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>
At the moment the timed login feature is implemented in the user list.
If there's no user list, we don't show the indicator anywhere and
don't proceed with timed login.
This commit allows timed login to work when the user list is disabled.
It accomplishes this by putting the timed login indicator on the
auth prompt in that scenario.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1809>
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>
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>
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>
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>
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>
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>
This was forgotten when porting to GTK 4, leading to the following error
when user tries to copy the error message produced by an extension:
JS ERROR: TypeError: Gtk.Clipboard is undefined
_initActions/<@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:255:31
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:177:20
main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
run@resource:///org/gnome/gjs/modules/script/package.js:206:19
start@resource:///org/gnome/gjs/modules/script/package.js:190:8
@/nix/store/fwnkwvhwm3kqck4fhkc5y5z853radggg-gnome-shell-40.0/share/gnome-shell/.org.gnome.Shell.Extensions-wrapped:7:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1795>
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>
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>
`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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
When adapting the check to the new versioning check, we just blindly
copied the old behavior for stable/unstable versions:
- stable releases must have matching major numbers
- unstable releases must match major and minor ("alpha", "beta", "rc")
That worked for the old even/odd scheme, but now has the absurd effect
that we consider an extension that lists "40.alpha" in its shell-version
incompatible with "40.beta", but compatible with "40.2".
At least this provides us with a good opportunity to reconsider the
behavior. While it is true that breakage is much more likely between
unstable releases, in practice extensions are either following shell
development closely or update once around the time of a stable release.
For the former, the stricter check isn't usually too useful (as the
extension releases around the same time as gnome-shell anyway).
For the latter, it's annoying that ".rc" is treated differently from
".0" and requires an update to become compatible.
The latter is also by far the more common case, so update the check
to only match on the major version regardless of whether a release
is stable or unstable.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3787
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1719>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
When we got an error, all the other HINT or INFO messages are not useful
anymore and delaying to show them is just a waste of time and may be
even wrong in scenarios with fast authentication devices.
An example are the fingerprint devices, where the user may touch the
sensor repeatedly while we may still show the "touch the sensor" hint
instead of notifying of possible errors.
So, in case we got an error override all the other errors coming from
the same service with lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
Once the verification has been stopped or has failed all the messages
that are not of error type are just not needed or wrong to show.
For example, in the fingerprint case we may still show the hint to swipe
or touch the device, while the fingerprint PAM service has already been
stopped.
So filter them by adding a new function that adds a null message to the
queue, overriding all the messages that have a lower priority.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
There are cases in which a service may want to override a message with
one coming with higher priority, for example an info or hint message
isn't useful anymore if we've already got an error message.
In the same way when a service has been stopped we don't care anymore
showing its info or hint messages, while it still may be relevant to show
errors.
An example is the fingerprint service that may emit errors quickly while
the hints messages should not be kept around when an error is already
queued or when the service has been stopped.
So, add function that allows to override queued messages based by their
type that follows this policy:
- Messages coming from different services are always preserved in
their original order.
- Messages (from the same service) with a priority equal or higher than
the last queued one are preserved.
- Messages matching completely the last queued are dropped in favor of
this one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
It can be convenient to get the currently showing message in order to
replace or remove it in case it's not needed anymore.
So simplify the message queue handling by only depending on a single
local variable (_messageQueue) and redefining hasPendingMessages
depending on its content.
Now messages are kept in queue till they are not fully processed and the
first message is always the one currently shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
When a fingerprint failure event happens we may also soon receive a
conversation-stopped event with an error message (such as in the case
we hit the MAXRETRIES value), but this is going to be ignored in case we
are too quick in consider the first failure a verification-failed event
because that implies disconnecting from all the events and then ignoring
such signals.
To prevent this, add a small timeout before failing the verification so
that if we get a further event we will process it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it, however this can lead to
troubles since commit 7a2e629b as when the service conversation was
stopped we had no way to figure out this case and we'd end up to
eventually fail the whole authentication.
However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.
So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error as we did before commit 7a2e629b, without bothering
failing the whole verification.
In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3734
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>
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>
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>
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>
Currently when the foreground service conversation stops we increase the
verification failed count and try to start it again, while if a
background service has been stopped we just ignore it.
This is causing a various number of issues, for example in the case of
the fingerprint authentication service, it is normally configured to die
after a timeout, and we end up never restarting it (while the UI still
keeps showing to the user the message about swipe/touch the device).
So, in such case let's just consider it a "soft" verification failure
that doesn't increase the failures count but will cause us to reset the
UI and try to restart the authentication (and so the affected service).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Wiggle may make the error message to be visible for less time so provide
the auth prompt an API to increase the timeout to be used for showing a
message in some cases.
This could be reworked when we'll have a proper asyn wiggle function so
that we could just make the user verifier to "freeze", then await for
the wiggle transition to complete and eventually release the verifier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Currently whenever an authentication failure happens we wiggle the
entry, however this may not be related to the service which failed.
For example if the fingerprint authentication failed for whatever reason,
there's no point to wiggle the text input as it's something unrelated to it.
So, only apply the wiggle effect to the entry in case the failure is
coming from the querying service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
By giving to the AuthPrompt information regarding the source service
name (and so the ability to know whether it's a foreground service) can
give it the ability to behave differently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Fingerprint PAM module can have multiple failures during a runtime
and we rely on the pam module configuration for the maximum allowed
retries.
However, while that setting should be always followed, we should never
ignore the login-screen's allowed-failures setting that can provide
a lower value.
So, once we have a fingerprint failure let's count it to increase our
internal fail counter, and when we've reached the limit we can emit a
verification-failed signal to our clients.
As per this we need also to ignore any further 'info' messages that we
could receive from the fingerprint service, as it may be configured to
handle more retries than us and they might arrive before we have
cancelled the verification session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
Decouple the verification failure count increase from
_verificationFailed as there are some cases in which we may want to
increase it without emitting a verification-failed signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
When the login/lock screen is shown the error messages for background
services are always ignored.
However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.
This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.
Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.
[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>
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>
This ports the runDialog changes of [1] to the underlying history
component, where they can benefit looking glass as well: the history is
now responsible for trimming the input and deciding that it shouldn’t be
stored if empty. (Note that _setPrevItem and _setNextItem already
skipped updating the history if the entry was empty.)
Since both users, runDialog and lookingGlass, also need the trimmed
input for other reasons – runDialog to avoid issues when interpreting
the command as a file path (if it can’t be executed as a command),
lookingGlass to decide whether a command should be run at all – have
addItem return the trimmed input. (runDialog and lookingGlass are not
yet changed to take advantage of this – that will be done in separate
commits.)
[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
When verification failed using a specific authentication service we're
currently restarting the whole user authentication system, which leads
to lots of unneeded operations (reinitializing a new user verifier proxy,
restarting all the gdm workers with the relative PAM modules and so on).
And this makes also debugging of login problems more complicated, given
we're cluttering the journal with repeated data.
However, at reauthentication failure GDM has already set up for us an
user verifier that we can use reuse to start only the service that had a
failure. So when possible, just start a new service instead of rebooting
the whole authorization process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.
Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).
So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
In case a background service such as the fingerprint authentication
fails to start we'd just mark the whole authentication process as
failed.
Currently this may happen by just putting a wrong password when an user
has some fingerprints enrolled, the fingerprint gdm authentication
worker may take some time to restart leading to a failure and this is
currently also making the password authentication to fail:
JS ERROR: Failed to start gdm-fingerprint for u: Gio.DBusError:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.Failed:
Could not create authentication helper process
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
### Promise created here: ###
_startService@resource:///org/gnome/shell/gdm/util.js:470:42
_beginVerification@resource:///org/gnome/shell/gdm/util.js:495:18
_getUserVerifier@resource:///org/gnome/shell/gdm/util.js:405:14
async*_openReauthenticationChannel@resource:///org/gnome/shell/gdm/util.js:378:22
async*begin@resource:///org/gnome/shell/gdm/util.js:194:18
_retry@resource:///org/gnome/shell/gdm/util.js:561:14
_verificationFailed/signalId<@resource:///org/gnome/shell/gdm/util.js:584:30
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:268:14
_queueMessageTimeout@resource:///org/gnome/shell/gdm/util.js:273:18
_queueMessageTimeout/this._messageQueueTimeoutId<@resource:///org/gnome/shell/gdm/util.js:288:65
Given that background services are ignored even for queries or any kind
of message, we should not fail the authentication request unless the
default service fails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a verification session has failed we may want to wait for the user
to have completed all the waiting queries and to have read all the
incoming messages, however during such time an user verifier should
not be allowed to queue further messages to the UI, as we're about to
completely stop the identification or start a new one.
Unfortunately this is not true because we're still connected to the
identifier signals, and so we may still show messages.
This is particularly true when using the fingerprint PAM module as it
may restart the authentication while we're in the process of stopping
it.
So, keep track of all the signals we've connected to, and disconnect on
verification failed and during cancel/clear operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Answering a query may be delayed to the moment in which we've not any
more messages in the queue, however this case can also happen just after
we've cleared the UserVerifier and in such case we'd have nothing to
answer, but we currently throw an error:
JS ERROR: Exception in callback for signal: no-more-messages:
TypeError: this._userVerifier is null
answerQuery/signalId<@resource:///org/gnome/shell/gdm/util.js:249:17
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
finishMessageQueue@resource:///org/gnome/shell/gdm/util.js:266:14
_clearMessageQueue@resource:///org/gnome/shell/gdm/util.js:301:14
clear@resource:///org/gnome/shell/gdm/util.js:223:14
cancel@resource:///org/gnome/shell/gdm/util.js:205:18
reset@resource:///org/gnome/shell/gdm/authPrompt.js:482:32
cancel@resource:///org/gnome/shell/gdm/authPrompt.js:569:14
vfunc_key_press_event@resource:///org/gnome/shell/gdm/authPrompt.js:128
So handle this case more gracefully keeping track of the current
cancellable and checking whether it is still valid before trying to answer
a query or do a delayed action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
As per previous commit the user can cancel an ongoing authentication via
Escape key and that will always send the user back to the clock view in
lockscreen or user-selection view in login prompt.
However, we can be a little more permissive and don't switch view to be
able to restart the authentication without further action.
To avoid this to be abused though, we consider the user verification
cancellation via escape key to be a "soft-failure", so once the
configured "allowed-failures" gsettings value has been reached, we'd
just act as before, ignoring any further request (until we don't get
back to the user auth view).
In this way we still make brute-force attacks harder to do, while still
giving the well-behaving user some ability to fix mistakes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
Escape key is supposed to cancel a verification, however if the user
already hit Enter to begin the authentication the Escape key won't work
until the verification completed.
This may be quite inconvenient when an user did a typo while writing and
wants to cancel the already started auth.
So, while authenticating (or in general while the entry is unsensitive)
give the key focus to the authpromt itself so that we can still get the
input events and cancel an user action.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When a cancel event in the user lockscreen happens we first emit a reset
signal and immediately a cancelled one.
This lead to start a new gdm worker for each enabled authentication
method and then immediately to stop it.
As per the previous commit, we don't have anymore dangling gdm workers
around, but still we should not even start a new one in such case.
So, when the user explicitly cancelled the authentication session, first
emit a cancelled event and only emit a reset event with a begin request
if we are outside the lockscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
When we cancel an user authentication via Escape key or cancel button on
AuthPrompt we reset the view and we emit a 'cancelled' signal that leads
to destroying the auth prompt and the user verifier.
However, the verifier may still have an operation in progress and its
completion may take some time (as in the case of gdm-fingerprint), but
we just leave the gdm worker running until its pam module completes
(potentially never) clearing and disposing its handle.
So, instead of just clearing the verify, actually cancel and clear it.
In case the user verifier is set, clearing the relevant data will happen
anyway as part of the cancel() call.
Ideally this would have been handled by gdm itself, but unfortunately we
can't fix it there because the verifier itself is a class generated by
gdbus-codegen, so we can't handle this automatically on disposal nor we
can automatically monitor when the caller proxy is stopped on our side.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>
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>
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>
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>
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>
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>
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>
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>
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>
It makes more sense in a spatial overview that the app grid
comes and goes to somewhere in the screen, instead of fading
in and out into the void.
Make the app grid rise from the bottom of the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Move AppDisplay, WorkspacesDisplay, and ThumbnailsBox from ViewSelector to
ControlsManager. This allows to always allocate the correct size for AppDisplay,
and will enable for a plethora of further improvements. The end goal is to
completely remove ViewSelector, and let ControlsManager handle the layout of
everything that's visible in the overview.
For now, replace the apps page with a dummy actor in ViewSelector.
Adjust various callers around the codebase to not access the ViewSelector
directly from the overview anymore.
Bind the opacity of the primary workspace to WorkspaceDisplay's opacity. This
allows removing the parent opacity hack in place, which will be done by the
next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Now that Overview is able to ease into any state, be it window
picker or app grid, we can move this ViewSelector method to
Overview itself, which is its rightful place to live.
Remove ViewSelector.showApps(), and make all callers call
Main.overview.show(ControlsState.APP_GRID). Also make sure the
show apps button is correctly toggled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Next commits will requires ControlsManager to animate to different
states, depending on how Overview is called. Add a new 'state'
parameter to ControlsManager's, and OverviewActor's animateToOverview,
and Overview.show().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Remove Workspace.zoomTo/FromOverview(), they're unused now. Rename
everything up to ControlsManager to prepareToEnter/LeaveOverview(),
since these classes don't run the animation anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
WorkspacesView uses the floating layout when the overview is in window
picker mode, and the session layout when the overview is in app grid
mode. Up until now, the fit mode adjustment was used to derive the
workspace mode, but it is incomplete as it doesn't have the full range
of workspace states.
Make ViewSelector cascade the overview adjustment to WorkspacesDisplay,
and use the overview adjustment itself to derive the workspace mode.
Extra workspaces don't have to account for the fit mode, and thus are
basically a clamp(state, 0, 1) of the overview state. However, don't
call animateTo/FromOverview() anymore, since they ease the workspace
mode adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Boy, does this commit feel good.
While the workspaces view on the primary monitor *appears* as part of
the overall overview hierarchy, this hasn't actually been the case
until now. We synchronized its size and (stage) position to match
the workspaces display, but actually kept in a separate layer for
the transitions to and from the overview.
But now that the new layout manager slides out completely during the
overview transitions, the workspaces display starts out covering the
entire work area, which is exactly what we need for the transition.
So finally stop faking it, and actually make the primary workspaces
view a child of the workspaces display.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of delegating it to ViewSelector, make the transition to and from
overview ease the main state adjustment.
This commit temporarily breaks these animations, but on the other hand
introduces an important feature: ViewSelector is always allocated to the
actual size. This will finally allow for adding WorkspacesView as a child
of WorkspacesDisplay, and finally remove the actual geometry hack, which
is what next commit is about.
This commit also effectively reverts b64103efc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of directly accessing ViewSelector and calling these methods
there, cascade the calls to OverviewActor, ControlsManager, and finally
ViewSelector. Also move the opacity transition to OverviewActor.
This commit has no functional change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, ActivitiesContainer reacts to showAppsButton and
transitions between app grid and window picking states on
its own. In the future, we want full control over this.
ControlsManager already has a state adjustment that represents
all possible overview states. Propagate this adjustment up to
ActivitiesContainer, and use it to drive the transition.
This requires moving the callback to the showAppsButton to
ControlsManager, since now it control the state adjustment
itself, not ActivitiesContainer's adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
In the future, we want to tightly control the state of the
layout throught gestures, which requires hooking everything
together with adjustments. This is the first step in this
direction.
Add a new custom layout manager for ControlsManager that
allocates the search entry, the view selector, and the Dash,
vertically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, gnome-shell uses the wrong scrolling direction for
horizontal scrolling events.
When dx < 0 for a smooth scroll event, then the scrolling direction is
supposed to be Clutter.ScrollDirection.LEFT, instead of
Clutter.ScrollDirection.RIGHT, as dx is smaller than 0.
Fix this issue by swapping the values LEFT and RIGHT.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1665>
It is possible for an initiated session to complete without
a request if polkit can authenticate the action without user
input. We fail to clean up after ourselves in that case, as
the cleanup is done after the dialog is closed.
The dialog can still be shown when the code that hides existing
dialogs while the screen is locked shows it on unlock. But as
the session was closed, the dialog is now defunct and cannot
be dismissed by the user.
Fix this by running the cleanup on close() when the dialog
wasn't shown.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3701
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662>
The children variable holds the icons that were originally in
the dash. For the separator visibility, we should consider the
icons that are in the dash after the update, so we must consider
additions as well as removals.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1659>
Previously we used a bunch of heuristics for this. We checked if velocity
was directed towards the nearest snap point and its value was larger than
a threshold. If it is, we completed the swipe, otherwise we cancelled it.
This was good enough at the time, because this code was originally written
for back/forward swipe. Since then, the swipe tracker was extended to
handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
on text direction. After that it was iterated on, but never significantly
redone.
This worked well enough, but had two problems:
1. In some cases, notably overview, it may be wanted to be able to swipe
through multiple pages at once. This wasn't really possible because we
always picked the adjacent snap point.
2. Since we can't do that well, we want to restrict swipes to one page at a
time. It was done in a rather hacky way by clamping the position into
[-1, 1] range from the place where we started the swipe. This works
if we start the swipe from idle position, but if an animation was
already going, the range would be clamped to arbitrary values, and very
likely containing only one snap point, which we already swiped past at
this point. In this case, finishing the swipe would cancel it regardless
of velocity. This means that if one tries to quickly move through
carousel pages via swiping, half of the swipes will be inexplicably
cancelled.
We'll use the deceleration formula from
https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
to calculate then projection point, then pick the nearest snap point and
calculate the duration as we did before. It works well enough for short
distances, but has two problems:
1. It caps the maximum distance at a pretty low value - about 5 pages in my
testing.
2. With how we pick the nearest snap point, it's too easy to accidentally
cancel the swipe,
To combat the first problem, we can modify the curve: only use linear
function at small distances, and smoothly transition it to a parabola
further.
For the second problem we can add two special cases: first, if the swipe
ended up between the initial snap point and the next one, we always prefer
the latter. Second, a good old velocity threshold for cancelling.
We'll also use a slightly smaller deceleration value for touchpad: 0.997
instead of 0.998.
Now that we can pick any snap point, the [-1, 1] clamping doesn't make
sense anymore, so instead let's replace it with a more flexible
mechanism: if we're near a snap point, pick its adjacent snap points.
Otherwise, take the two nearest snap points, and take their adjacent
snap points. This way we have 3 snap points to choose from when
starting a swipe from an idle position, and 4 if we start during an
ongoing transition.
This way, if we've just swiped from snap point n to n+1, the transition
will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
likely land on n+2. During that transition, if we swipe again, it will
likely have already passed the snap point n+1, so this time the available
snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
still complete, and so on.
This will make it easy to allow multi-page swipes as well, by just
removing the clamping.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
In some cases we may get anevent with very low delta at the end of the
swipe. While we can't completely ignore them, we can smooth them using a
scroll history, similarly to what GTK kinetic scrolling does: keep track
of the last 150ms of events, and sum their deltas when calculating the
velocity.
The logic is based on what GTK does in GtkGestureSwipe and
GtkEventControllerScroll.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
The reason this wasn't using the Gio.DBus.makeProxyWrapper() convenience API is that it passes custom flags to the proxy, and that wasn't supported by the wrapper at the time.
As this is now possible, this commit migrates us to the new API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1572>
Let empty input result in an error, just like other invalid commands
(bad syntax, nonempty whitespace, etc.). GLib already has an error
message “Text was empty (or contained only whitespace)” which it shows
for whitespace-only input, so letting that message apply also to empty
input makes sense.
This requires some tweaks further down the file to avoid interpreting
empty input as an empty path (relative to the home directory) and then
opening the home directory.
Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.
That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.
Fix this by using a custom name for a custom icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
The Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.
Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3664
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1632>
grabHelper is passing a boolean argument to onUngrab() callback function
and since commit 1acbdcc9b3 we'd end up adding it to to the callback list or
we'd try to invoke it:
(gnome-shell:3490851): Gjs-CRITICAL **: 17:19:20.460: JS ERROR:
TypeError: func is not a function
onComplete/<@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:56
onComplete@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:40
_makeEaseCallback/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:85:13
_easeActor/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:170:64
Use an arrow function so that we can control the parameters we pass
to popdown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1635>
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
So far, we couldn't allow workspace scrolling outside the overview
because scroll events were always sent to clients. However mutter
was changed recently to pass on scroll events when the mouse button
modifier (usually super) is pressed, which allows us to enable the
same workspace scrolling as in the overview now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The design now calls for super-scroll for workspace switching
in the session, however it is currently only possible for
SwipeTracker to either handle scroll events or not.
In order to support the new use case, add a new :scroll-modifiers
property that allows specifying modifiers for which scroll events
are handled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The code to update the actor position based on the cursor and current
scale was run in a 'new-frame' handler. This is working fine when
animations are enabled, but when they are turned off this does not work.
This is because the 'new-frame' signal is emitted before the changes for
that frame are applied. So with animations off the position was only
ever updated with the starting values. As a result the shrunk actor was
not being dragged by the position where it was clicked, but by where it
was clicked in the original size, which is likely not even on the shrunk
actor.
This change now also updates the position in the onComplete handler
which gets run with the final scale, even if the duration is 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1627>
Next commit will bind the workspace state adjustment to the snap
adjustment in WorkspacesView, and we'll need the preparation
steps but not the easing of the state adjustment.
Split preparation steps from zoomFromOverview() into a new method
prepareToLeaveOverview().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
As per the latest mockups, then horizontally snapping, the active
workspace should be highlighted. Because WorkspacesView clips to
allocation, we cannot simply scale up the active one. Instead,
scale down the inactive ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Synchronizing the actual geometry while animating from / to the overview can
break the animation. Let's prevent that. This code will go away soon anyway,
but to not lose bisectability, it's better not to leave it misbehaving until
then.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
When vertically snapping, WorkspacesView currently allocates workspaces
side-by-side, then applies an extra step of translation to center to
the active workspace. This extra step, however, gets in our way because
now we need tighter control of the workspaces positions in allocation,
in order to properly interpolate them.
Move the translation of workspaces to the allocation code itself, and
remove the extra translation step.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Currently, WorkspacesView positions each workspace on a
per-page layout, each page with the allocated width and
height of WorkspaceView. This layout doesn't work well
with horizontal workspaces.
Layout workspaces side by side, instead of per page. The
layout is influenced by a "fit mode", which reflects the
different behaviors exposed in the mockup. This fit mode
represents whether a single or all workspaces will fit
available geometry.
The single fit mode is always used for now. Next commits
will make it switch to the all fit mode when in the app
grid state.
The translation_{x,y} also needed to reflect the switch to
a side-by-side layout, and use the geometry of the workspaces
to determine the offset. Notice that, when the fit mode is ALL,
there's no translation applied.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Nowadays gjs allows to omit get/set accessors for read-write properties,
and will define reasonable defaults in that case. In many cases we don't
need anything more than the default handling, let gjs handle those props.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
The app grid itself now is horizontal, and is displayed beneath
workspaces, above the dash. This makes the indicator animations
out of place, as they're not coming from the edge anymore.
Use PageIndicators for both FolderView and AppDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1629>
The new window preview overlay requires getting the app icon for a
window from the window tracker when it gets initialized. The window
tracker listens for the same 'window-added' signal on the MetaWorkspace
that the gnome-shell Workspace listens for to add the window preview.
The window tracker however reconnects all its signal handlers whenever
the number of workspaces changes, which means that its signal handlers
get called after the ones in Workspace ones. So by the time the
'window-added' handler in Workspace is called, the window tracker does
not have an app associated with the window.
To fix this ensure that all window related signal handlers in Workspace
are run after the ones in the window tracker.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3656
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1625>
Currently, there's one animation for the whole canvas. While it looks fine
with just one screen, it causes windows to move between screens when
switching workspaces. Instead, have a separate animation on each screen,
and sync their progress so that at any given time the progress "fraction"
is the same between all screens. Clip all animations to their screens so
that the windows don't leak to other screens.
If a window is placed between every screen, can end up in multiple
animations, in that case each part is still animated separately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1213
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
Currently, the workspace swipe transition only has one workspace in each
direction. This works until you try to do multiple swipes in quick
succession. The second swipe would continue the existing transition, which
only has 2 or 3 workspaces in it, and will hit a wall.
To prevent this, take all workspaces and arrange them into a column or row,
depending on the layout, and use that as a transition.
For the transition that happens when focusing a window on another workspace
(for example, via Alt+Tab), still use only two workspaces instead of all of
them.
Since we don't support layouts other than single rows/columns anymore,
diagonal transitions aren't supported anymore, and will be shown as
horizontal or vertical instead.
Since nw alt-tab and gesture transitions are different, don't allow to do
both at once, that is, disable swipe tracker when a programmatic transition
is going. This will also conveniently cancel a gesture transition if a
programmatic one is initiated while a gesture is in progress.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2612
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
In future we will need to use window clones to better support multiple
monitors. To avoid having to hide every window, show wallpapers behind
the workspace transition: one per monitor.
Put the wallpaper into a separate class right away, later it will be
useful to make the animation per-monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
