If the cursor was placed on one of the widgets that get removed when
rebuilding the calendar due to a month change, destroying the hovered
widget will trigger a repick. This repick can then trigger an allocation
while not all buttons of the calendar are present.
If the last allocation before selected-date-changed is emitted was from
such an incomplete state, DateMenuButton will still freeze the layout in
this state in its signal handler.
What freezing the layout in DateMenuButton is supposed to do is to
prevent size changes of the menu when changing days, but for this the
layout needs to be frozen before potentially rebuilding calendar. This
change ensures that by emitting the signal earlier.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5411
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5469
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2989>
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.
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.
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._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>
