Since the launch context may also be used to activate an action on an
running application with an already existing window, which we don't
necessarily want to move to a different workspace, don't set a workspace
for the launch context. If no active window exists for an application
then it will be place on the currently active workspace anyways.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
There are multiple different places where we activate an app action,
but none set the correct activation token. Therefore this adds an async
method to to call `ActivateAction` on `org.freedesktop.Appliaction`
with the correct activation token/startup id as platform data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
Ideally, the use case we have for MetaGroup would be removed but that
requires investigation that could be done as a future step
The function also expects a MetaWindowX11, so add a check to ensure
we don't crash at runtime if the function gets called on a wayland
client
Also removes an unused header import
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3157>
It sounds strange that buttons would admit Pango markup
in their label text. It sounds better to default to plain
text, and let users wanting markup to access the child
directly.
This also makes the first label being set consistent
with later text being assigned wrt markup usage, since
the non-markup ClutterText API is used if the child is
already present and of the expected type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3149>
St.Icon is very commonly used for displaying themed icons, yet so
far updating the icon on icon theme changes is left to the caller.
Unsurprisingly, very few actually do that, with the result that
for most icons, icon theme changes only take effect after a delay
(say, a color change on hover) or not at all.
This is also inconsistent with GTK, where Gtk.Image will automatically
pick up icon theme changes.
Address this by tracking whether the current icon corresponds to
a themed icon, and update it automatically on theme changes if
it does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
Since StDrawingArea is the only user of ClutterCanvas, it is possible
to move ClutterCanvas completely out of Mutter to gnome-shell. This
allows to remove another Cairo dependency from Mutter.
This patch merges ClutterCanvas code extracted from Mutter to
StDrawingArea.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3098>
Since commit ed3b8d093e16, the actor's single-child policy is
enforced even when using the generic add/remove_child() methods.
This makes it possible to follow GTK/AdwBin's lead and replace
out custom child allocation with a BinLayout, without changing
the actor's semantics in a fundamental way.
However this does change slightly how the child is allocated, as
it now only expands according to its expand properties, not when
the alignment is set to FILL.
Even after the preparations in the previous commit, some fallout
is still likely, but it will be easy to address, and the cleanup
is significant enough to justify it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3046>
We have considered .desktop files a required app component for
more than 10 years now. It also has been several years that the
default session switched to wayland, which doesn't have protocol
for window icons.
So stop using an elaborate fallback path just for legacy clients,
and just fall back to the same generic icon we use for wayland
clients.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3056>
Requires mutter!1908 first.
So now consumers of the clutter blur code don't have to know the
implementation is Gaussian and no longer need to convert the intended
blur radius to a sigma value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1905>
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>
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>
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>
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>
