Extensions like dash-to-dock use set_icon_geometry() to window.
This changes the dest and scale of ease animation of minimize and
makes it looks very strange. By setting dest opacity to 0 the animation
could be more natural.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2968>
(cherry picked from commit 5d1a0cc525)
Returning a GLib.Error from a method invocation will encode the
error when sent over the wire. In case the error itself is already
an encoded remote error, just passing it on will result in double
wrapping.
Avoid that by stripping any remote error information before
returning it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
(cherry picked from commit a5d33026f0)
Pipelines for non-protected branches are set to 'manual', and
thus cheap. However they may still get picked by `@marge-bot`,
meaning that the bot waits for the completion of a pipeline that
never starts.
Avoid that by not creating pipelines for branches with open
merge requests.
Credit to Jordan, who came up with this for gst.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3153>
(cherry picked from commit d3e96a36ce)
If something grabs the key focus while a modal is pushed, keeping
key-focus on that actor seems like the smarter thing to do than setting
it back to the last focus after the modal gets popped again. So check if
the key focus actor that we set when pushing the modal got changed when
popping that modal, and if it got changed, simply don't touch key focus.
This fixes a bug with the close dialog, where key focus isn't correctly
set to the dialog after alt-tabbing to a window showing a close dialog.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
(cherry picked from commit 4d544d7b56)
When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
(cherry picked from commit de834fe307)
strstr() in find_class_name() will always consider "" a match so the
loop was not stopping at the end of the class_list. None of the matches
within the class_list would satisfy the return conditions, unless the
class_list was either an empty string as well or has a trailing space.
So this ends up with a match outside of the allocated string that
happens to satisfy these conditions by chance which then leads to the
class string containing some of this unrelated memory. Or it might lead
to a segfault.
This adds checks to the public API that uses find_class_name() to
prevent extensions from accidentally triggering a crash this way or
having some otherwise unexpected results.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7152
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3006>
(cherry picked from commit dc931e82cd)
The docs say that `st_adjustment_set_values()` emits the `changed`
signal only once but it's actually emitted for each changed property,
this uses the `dispatch_properties_changed` vfunc to emit the `changed`
signal only per call to `st_adjustment_set_values()`. As a positive
side effect this also makes it possible to use `g_object_freeze/thaw_notify`
to compress the `changed` signal emission when using the setters for
properties.
This also fixes the wrong emission of the `changed` signal in
`st_adjustment_set_values()` when only the `value` property is changed.
Side note: the code is heavily inspired by GtkAdjustment
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3023>
(cherry picked from commit 78eb5f2a68)
We hide scrollbars with POLICY_AUTOMATIC when the content of the scroll
view fits completely inside the view without having to scroll. In this case
it seems like a good idea to give the content the full available size
without subtracting scroll bars from that size.
So subtract the scroll bar from the size we give to the child only when
the scroll bar is actually visible, when it's invisible subtract 0 instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
(cherry picked from commit 65e56183b1)
StScrollView applies the policy of whether to show or hide the scroll
bar,
and with the AUTOMATIC policy the scroll bar should be hidden as soon as
the
content of the scroll view is small enough to fit without scrolling.
Now we only know about the final size of the content when we're inside
st_scroll_view_allocate(), so that's where we can decide whether the
scroll
bar should be visible or not. Clutter really doesn't like calling
clutter_actor_show/hide() in the middle of an allocation cycle though,
so
what we do instead is saving the state into priv->vscrollbar_visible,
and
then just not painting the scroll bar based on that in a paint() vfunc
override.
This approach is not great for several reasons, it means we also have to
override pick() and finally it means the paint volume of the scroll bar
is
incorrect.
While the greatest solution to this would be to just hide/show the
scroll
bar inside the allocate() function as it is possible in gtk, we have an
established pattern for this kind of case too: We usually allocate a
0-sized
rect for the thing we want to hide, so let's do that instead.
A nice side effect is that we can conveniently drop another paint() and
pick() vfunc override.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
(cherry picked from commit a59a992daa)
As per the warning emitted when destroying without closing first
GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed.
You must explicitly end the data stream to the loader before dropping the last reference.
closing it is necessary.
Create the GdkPixbufLoader after loading the file contents so that
the loader is guaranteed to be closed before it is destroyed.
(`gdk_pixbuf_loader_write()` closes it on failure.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3008>
(cherry picked from commit 3e7027821d)
When GridSearchResults::_getMaxDisplayedResults() is called after the
first character has been entered in the search, GridSearchResults has
no children yet. _getMaxDisplayedResults() tries to determine the
maximum number of search results based on how often the largest child
would fit into the allocated size or -1 (i.e. no limit) if there are no
children. So for the initial search there is no limit and in the app
search all matching apps get added as possible results, which due to the
search term being only a single character is almost all installed apps.
This now causes allocation to be run for all these results, despite the
vast majority of them never being visible, which on slower machines can
cause noticeable delays before the search results are displayed.
This now adds the ability for search providers to specify a maximum
number of results that gets used instead of -1 when specified. By being
provider specific this means extensions implementing their own providers
will not be affected by this.
Further this sets the maximum for the app search provider to 6 as per
the current designs.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7155
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3004>
(cherry picked from commit 9153876764)
PopupMenuManager was connecting to notify::key-focus on the stage on
construction, but only ever reacting to it when one of its menus was
open. Given that every single app icon and text entry creates a
PopupMenuManager this was causing a lot of these handlers to be created.
Every single handler meant calling into JS code only for the vast
majority of them to determine that they would not do anything.
Additionally these handlers were leaked for the whole lifetime of the
stage due to never getting disconnected.
This now only connects the handler when a menu is open and disconnects
again when it is closed, significantly reducing the number of active
handlers at a time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7143
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3001>
(cherry picked from commit f1b7af2ab0)
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>
(cherry picked from commit 23bcff3348)
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>
(cherry picked from commit a94fcee961)
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>
(cherry picked from commit 050d0e10c7)
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>
(cherry picked from commit bc3b890e75)
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>
(cherry picked from commit 08f3ad3835)
