When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
The thumbnails actor `this._thumbnails` has already been destroyed when
calling `_destroyThumbnails()` from the `destroy` signal handler because
it is a child actor of the AppSwitcherPopup. So stop destroying the
thumbnails separately (fading them out inside a destroy handler wouldn't
make sense anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The correct property for the scroll-direction with scrolling events is
`direction`, no `scroll_direction`. This fixes scrolling in the alt-tab
popup, which broke with the actorization changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
When the switcherPopup was initiated successfully, we return true,
otherwise the WindowManager will try to destroy it. Since an early
release of the keystroke will also switch to another application and
close the switcher just fine, we should return true to indicate success
here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Right now the index that gets selected on click and motion events is set
when connecting the event inside the addItem function. If items are
added or removed (for example when an application is closed by pressing
"q"), this index isn't valid anymore and has to be updated.
To fix this, use the items themselves instead of the index as arguments
for the event handlers and lookup the index of the item inside the event
handler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Set the accessible states of the switcherList items by calling a
function instead of manipulating class-internal variables from outside
the class, which is considered bad practice.
The check whether the item at `_selectedIndex` exists can also be
removed since we always select a new index after an item was removed
(i.e. an app was closed) and destroy the alt-tab switcher right away if
no more items exist (see `SwitcherPopup._itemRemovedHandler`).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Limit the minimum and maximum value to scroll to inside the box to 0 and
the upper limit, for some reason this was done right in _scrollToRight,
but not in _scrollToLeft.
This fixes the behavior of scrolling to the left: Before, scrolling one
item to the left moved the view to the first element of the list (this
can make the selected element invisible in large lists). Instead, scroll
one item to the left, just like scrolling to the right works.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Make sure the index that's being scrolled to doesn't change while the
scrolling animation is running by using an argument instead of the
this._highlighed class scope variable.
This fixes wrongly shown arrows when selecting new elements faster than
the scrolling animation takes for one index. The check run to disable
the arrow might be checking against a newer index than the one at the
start of the animation which results in the arrow not getting hidden
even if no more scrolling is possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Since this._highlighted is always set to the currently highlighted
index, there's no need to save the index to a separate variable. This
obviously depends on getting the new item highlighted as a result of the
item-entered event.
This fixes bugs in situations where the highlighted element changes
after an event that is not calling _onItemEnter, for example after
scrolling or pressing a key. In those cases the _currentItemEntered
variable wouldn't be updated and the old item couldn't be entered
anymore without entering another one before.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
If the sessionMode does not allow to show the overview, we should also
hide an already visible overview.
This fixes a bug where, if the lockscreen was shown while the overview
was visible, the Ctrl+Alt+Tab popup would allow navigating inside the
overview because the overview actor is still mapped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1043
If a transition is reversed, the final property values will be the
same as before the transition. However this currently only works
correctly when we actually use a transition; to fix this with a
duration of 0, simply skip the set() call when the transition is
reversed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1042
While the unread messages indicator is updated when starting a new
session because we call _onSourceAdded() on existing sources, we should
also update the do-not-disturb setting which might still be enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1037
We turned both the auth prompt's cancel button and the switch user
button into icon buttons now, which means they are completely cryptic
when using a screen reader.
Just use the previously used labels as accessible names, which has the
nice side effect of lowering the impact of the string freeze break.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
Since commit mutter/a2a8f0cda we force the focus surface of the
meta-wayland-pointer to NULL while the pointer is hidden. This
introduced an issue with the magnifier, where we use
`set_pointer_visible` to hide the real cursor and show our own cursor at
the correct position: Because the meta-wayland-pointer is still used to
communicate with Wayland clients, the UI of the windows will not respond
to mouse movement anymore as soon as the real cursor is hidden.
To fix this, use the newly added clutter_seat_inhibit_unfocus() API to
temporarily disable unsetting the focus-surface while the magnifier is
hiding the system cursor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/993
If we are transitioning the label from 0 to its natural height, we
must set natural-height-set again after querying the preferred height,
otherwise Clutter would skip the transition.
However when transitioning in the opposite direction, setting the
property to true can go horribly wrong:
If the actor hasn't been allocated before, it will store a fixed
natural height of 0. But as there is no fixed min-height, we can
end up with min-height > natural-height, which is a fatal error.
(This isn't an issue when *actually* setting a fixed height, as
that will set both natural and minimum height)
So instead of always setting natural-height-set to true, restore
its previous value to fix the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2255
Now that we apply a strong blur effect to the background, it doesn't
make too much sense to use a separate lock-screen background: It will
be mostly unrecognizable anyway.
The alternative would be to turn off the blur effect if a different
background is used (or have a hidden setting for that), but that would
then imply that we must keep the contents readable without blur.
Let's avoid that rabbit hole and just re-use the regular background.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1001
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
`-slider-handle-radius` is a floating point value and even in the default
theme it's not a whole number. Regardless of the fractional part that's
still going to occupy a whole extra pixel with antialiasing. So make room
for it. Otherwise it looks clipped, which it is by the Cairo context of
its `StDrawingArea`.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
For reasons not yet fully understood, `Main.uiGroup.add_actor` takes around
10 milliseconds to complete.
Because of this, each `actor.opacity = 0` has a good chance of falling
on a different frame. And when it does, `_opacityChangedId` also lands
on multiple different frames each incurring a separate relayout cycle.
It is this excessive number of relayouts that causes stuttering in the
icon grid animation (#2065). But it is the slowness of `uiGroup.add_actor`
that causes the number to be excessive when it should be one.
By creating the clones and adding them to `uiGroup` early, we then enable
the existing loop starting the animation to complete within a single frame.
And by completing within a single frame all the opacity changes land within
the same frame interval, thus incurring only a single relayout instead of
many.
This issue went unnoticed until 004a5e1042 (!704), after which the slow
emissions of `notify::opacity` became a more visible performance problem.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2065https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1002
Now that the bind constraint changes the preferred size of
the actor, a major flaw in the AppDisplay code was exposed:
the folder dialog depends on the preferred size of a parent,
and the parent depends on the preferred size of the folder
dialog.
While we know this is not actually true, we shouldn't rely
on broken behavior to achieve this result. What's interesting
is that the bind constraint used by the folder dialog is a
relic of the development phase; we now control the position
and size of the dialog with a combination of CSS, and alignment.
Remove the unnecessary bind constraint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1027
Since the design of the notification popup changed with the theme
refactor and there are now boxes around the world-clock and weather
sections, the overlay scrollbar that is shown above them looks rather
bad. So simply hide that scrollbar, we still have the vfade effect to
indicate the container is scrollable and we also depend on that in the
new popup app-folders.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1013
Make sure the stylesheet properties of the window-chrome title are
updated before requesting the preferred width of the title to prevent
size changes of the title after we animated the width.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/58
Remove the default icon size of -1 and always set the container StBin to
a real size. This fixes an error where the "width" and "height"
properties get set to -2 (which is -1 * scaleFactor) in the `_init`
function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1018
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since quite a few strings of dialogs provided by external programs are
not updated yet and the string freeze is already in effect, make sure we
don't break those dialogs by stripping aways large parts of the
headline.
To do that, detect if the title label is larger than the available width
and if it is, switch to a smaller font-size of 13pt. This makes sure we
still show about the same number of characters in the headline as we did
in previous releases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1012
