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>
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>
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>
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>
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>
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>
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>
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>
It is a bit odd to have different default values for the vertical
and horizontal policy, but then that's what we almost always want in
practice: Automatic scrolling vertically, and no scrolling horizontally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
The scroll fade effect is the only component that accesses the
{v,h}scroll properties for anything other than getting access
to the corresponding adjustments.
Allow the effect to get what it needs via new private API instead,
so we can deprecate and eventually remove the scroll bar properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
The adjustments are currently only accessible indirectly via
the scroll bars. It is a bit odd to expose internal children,
and as nearly all users only access them for the adjustments,
it makes sense to expose those instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
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>
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>
These have been long deprecated over in clutter, and (via several
vtables) simply forward the call to the equivalent ClutterActor methods
Save ourselves the hassle and just use ClutterActor methods directly
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3010>
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>
