Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c85312f571e14abe69bb6674a361c16d65 we are sure that
duration 0 is always preserved.
In the not animate case, we now call this._updateState(). This was not
happening before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2987>
Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c85312f571e14abe69bb6674a361c16d65 we are sure that
duration 0 is always preserved.
In the not animate case, we now call this._actionBin.hide(). This was not
happening before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2987>
Windows of type DESKTOP are currently handled like all other sticky
windows, and stick to the monitor while the animation happens in the
background.
This behavior is odd for desktop windows, which are otherwise always
kept underneath regular windows.
Instead, make them part of the background, so they keep the expected
stacking position and animate together with the workspace.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2865>
Storing the pointer to the fade effect only works as long as we control
all the code that can modify the effects of an actor, but this is not
the case in the presence of extensions. Apparently some extension
manages to remove the effect, which leads to fade_effect pointing to
some invalid address by the time dispose is called, leading to a crash.
This instead uses clutter_actor_get_effect() to get the effect when it
is needed to avoid crashing in these situations.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6521
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2974>
Under certain unknown circumstances currently not every
`disable_unredirect_for_display()` gets matched with an
`enable_unredirect_for_display()` when closing the overview.
As we only want to not disable unredirection when hidden and we nowadays
have a state machine that ensures we transition to and from one state to
another only once, handle unredirection en-/disablement as part of the
state transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2970>
Both of these ended up with a "undefined" delta, which turned
the final value into 0 no matter the previous state.
While this was already fixed for touchpads in the previous commit
(by not forwarding emulated discrete events), this looks somewhat
out of place even for the mice that have left/right discrete scroll
actions (e.g. tilting the scroll wheel left or right).
Let these unhandled directions have a delta of 0, and focus on
vertical scroll for both smooth and discrete events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2967>
The pipeline contains a GST plugin that pops up an unclosable
zero-sized window.
Unfortunately we did not manage to come up with a proper fix
in time, so for now explicitly exclude it from app tracking.
This does not address all issues (it still prevents the
window's workspace from getting removed, even when it appears
empty), but at least it avoids the most confusing effect by
preventing the "app" from showing up in dash, alt-tab etc.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2956>
Currently we periodically check for updated extensions, prepare
an update and perform it at the next login.
This is largely due to the fact that once an extension has been
loaded, its code is cached and reloading it would only make it
*appear* as updated, while in reality still running the old code.
Of course this only applies *once* we have loaded extensions.
Before that, it's possible to download and install updates, and
only then initialize extensions with their latest version.
The trade-off is that network requests, data download and extraction may
introduce a significant delay before extensions
are enabled. Most extensions modify the UI one way or another,
so that delay would likely be noticeable by the user.
Assuming that users are usually happy enough with the current
extension version, that trade-off doesn't seem worthwhile.
However there is an exception: After a major version update,
extensions are likely disabled as out-of-date, or at least
more likely to break (when the version check is disabled).
In that case delaying extension initialization to download
and install updates looks like the better trade-off, so do
that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2951>
IBus requires XAUTHORITY and XDG_RUNTIME_DIR to be able to spawn its XIM
implementation correctly. Using launch context to get environment can correctly
launch on non-systemd setups.
Closes: #6998
Signed-off-by: xiaofan <xiaofan@iscas.ac.cn>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2947>
When commit 4d963c432b introduced the global workspace adjustment,
it mostly copied the adjustment handling from the overview that it
set out to replace.
That includes cancelling ongoing transitions when the number of
workspaces changed. However that missed that transitions don't
happen on the main adjustment, but on the "child" adjustments
returned from `createWorkspacesAdjustment()`.
Address this by tracking all child adjustments, and cancel transitions
there as well when necessary. Use weak refs to not
interfere with garbage collection, in case an extension creates
its own child adjustment.
Fixes: 4d963c432b ("main: Introduce global workspaces adjustment")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7000
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2949>
Reportedly, non-alphanumeric key levels were able to stick by
happenstance, and let the user press multiple keys until explicitly
switching to a different mode. Reportedly, this broke, switching to
the default level after the first key press on the additional levels.
Since we have this information in the OSK key models (each level has
a "mode" field to either default/latched/locked), retrieve this
information for them for each level, and only reset to the default
level if on one of those latched levels, and the relevant key was not
locked through long-press.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The _commitAction() paths have early returns, which made resetting the
latched mode inconsistent depending on the paths taken to commit the
string. This made latched modes not return to normal on e.g. Shell
entries.
Make this happen outside the function, and after the only calling
point, so that the level is correctly reset on all situations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
