Now that both the website and the Extension app support the custom
"version-name" field, we should expose it in the CLI tool as well.
As a more developer-oriented tool, keep showing the automatic
version along-side the new field when both are set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3034>
(cherry picked from commit ca47e7f8e3)
The extensions site recently added support for a custom
"version-name" string in metadata:
gitlab.gnome.org/Infrastructure/extensions-web/-/merge_requests/154
This allows developers to control the version that is exposed to
users. As the version according to the developer is almost always
more relevant than the automatic version assigned by the website,
use it instead of the "version" field if set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2995>
(cherry picked from commit 6db55eaea6)
After the port to ESM, an extension's `prefs.js` file is imported
asynchronously. An unintended side effect of that is that we now
show the dialog before anything can be added to the window (either
by the extension, or the fallback error UI).
The delay almost always won't be noticeable to users, but it's
bad practice and prevents extensions from using some API that
only works before the window is realized.
To address the issue, add a `loaded` signal to the dialog that allows
the caller to postpone showing the window until the UI is ready.
Close: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7201
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3025>
(cherry picked from commit 7f7ae31fa3)
Using an exported `init()` function to create the object is an odd
pattern, and not having the object referenced anywhere makes it harder
to access for debugging or extensions.
Just export the `EndSessionDialog` class and instantiate it like we
do for other objects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2997>
(cherry picked from commit 6ff08fd9bd)
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
(cherry picked from commit a6706bd2ca)
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
(cherry picked from commit a639fb0fc4)
I can't think of a reason why limiting the border to a maximum
would make any sense.
The original intention was probably to set a minimum border width
to avoid having to deal with border/no-border complexity in the code,
but as cairo accepts a line width of 0, it just works.
However limiting the size to the overall height seems reasonable,
as at that size a bigger height and different fill color can
achieve the same effect without requires special handling of
other values like the radius.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
(cherry picked from commit 77a72cec1e)
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)
The Eval() method currently evaluates the provided string, and
returns the result immediately. This isn't useful when a promise
is returned, which has become much more likely now that accessing
any module requires import().
Simply await the result, to handle both sync and async code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3021>
(cherry picked from commit f2601e6888)
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)
This reverts commit 575ba13b9b.
That commit did not actually prevent the "Unknown" application from
showing up in the dash or app switcher when the recorder was running,
but it introduced a problem with Proton which also uses gstreamer OpenGL
elements in its transcoder. This was causing the overview to get stuck
while the transcoder was running due to the app for the
"OpenGL Renderer" window being null.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7042
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3000>
(cherry picked from commit bf742c3926)
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)
Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c853 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>
(cherry picked from commit 1571171a21)
Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c853 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>
(cherry picked from commit be49c8efc2)
meta_window_raise_and_make_recent() now only works as advertised
for windows on the active workspace.
That results in the following unexpected behavior:
1. open two windows of an app (say: terminal)
2. open another app, maximize the window for best effect
3. switch to another workspace
4. super+tab to the first app: both windows are raised
5. close the window; instead of moving focus to the
2nd app window, both windows disappear because focus
is moved to the app from 2
This was fixed with new mutter API on the main branch, but
for the stable branch it is easier to work around the issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2959>
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>
