The reduced border radius from st_theme_node_reduce_border_radius() depends
on the allocation size, and when it changes, has_large_corners can change.
has_large_corners is used to determine whether to pre-render using cairo,
so that means a change to the allocation size can influence whether the
pre-render using cairo should happen or not.
On changes to the allocation size we don't want to call render_resources()
though, but just update_resources() instead. And since we know now that
changes to the allocation size might cause pre-rendering to get enabled
or disabled, we need to do the "should pre-render" checks in
update_resources(), too.
So factor out those "should pre-render" checks into a new function
st_theme_node_maybe_prerender_background(), and then call that function from
both render_resources() and update_resources().
This fixes rendering artifacts with borders or rounded corners after changes
to the actor size.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6567
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3354>
If the new CSS functions added in commit c593aecbde3
are used wrongly, an expected argument may be missing.
The code checks for that, but only after dereferencing
it to assign the next argument. Fix that by splitting
up the checks.
Spotted by coverity.
CID: #462818
Fixes: c593aecbde ("st/theme-node: Implement extensions for accent
color")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3380>
Add -st-accent-color and -st-fg-accent-color so that these colors can be
accessed from CSS.
Since they are often transformed in SCSS atm, add st-transparentize(),
st-mix(), st-lighten(), st-darken() that work in runtime.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2715>
Switch to render nodes. Most of the changes follow the pattern of
replacing a cogl_framebuffer_draw_*() call by (1) creating a paint
node, and (2) calling the corresponding clutter_paint_node_add_*()
API.
StWidget now overrides ClutterActor.paint_node(), instead of paint.
All subclasses that overrided the paint vfunc also are changed to
override paint_node.
The entry point for CSS rendering, st_widget_paint_background(), now
receives a root ClutterPaintNode, and propagates it to the rendering
machinery.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1538>
`g_desktop_app_info_launch_uris_as_manager_with_fds()` was added
in GIO 2.57.2. We now depend on at least 2.79.2, so we no longer
need a fallback path for the case the function isn't available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3361>
This was the type the function expected, but we were actually passing
the global context to it.
This didn't crash for some reason, but indeed it was wrong and we didn't
catch it because mutter side had not type-checks either
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3355>
Changing type when casting a double pointer is not strictly allowed in
C. In order to fix compilation with `-fstrict-aliasing`, don’t use
`g_clear_pointer()` for clearing this pointer where the type expected by
the destroy notify function does not match the type stored in the
`ShellCameraMonitor` struct.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3351>
In the shell code we often use GLib.spawn_async to launch processes
with a GSpawnChildSetupFunc implementation in JavaScript to reset the
mutter nofile rlimit in the new child process.
However, this is highly unsafe to do because this implies that the child
setup function code is executed in gjs where a lot of allocations are
done and even more not-async-signal-safe code is executed, in fact
leading to dead-locks as reported in the past.
To prevent this, declare a new functions that do the same of the GLib
counterpart but without providing a GSpawnChildSetupFunc that is instead
implemented in the C-side doing the cleanup that mutter requires without
allocations or async-signal-unsafe code.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
The child context setup function used as launch GSpawnChildSetupFunc
uses g_object_get that internally potentially allocates memory, making
it not async-signal-safe and so not something that is safe to use in
between fork and exec, so just use the simpler getter here.
Note that the current implementation of app_child_setup() is safe
already as sd_journal_stream_fd, dup2 and close are so.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
We build a small run-js-test executable so tests run in a
similar environment as gnome-shell, and then wrap it with
a generated script that provides environment variables like
GI_TYPELIB_PATH.
This is more complicated than it needs to be, we can just as
well set up the typelib search path from the runner and pass
in the environment via meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
It can be useful to know whether an icon displays a symbolic (rather
than just requesting it). Add a new :is-symbolic property for that
purpose, backed by private API on StImageContent that allows the
texture cache to shuffle that information through to the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
Currently we're using relative positioning when sending click events to
tray icon clients, and this leads to some apps (especially Qt ones) to
try to open the menus at such absolute coordinate under X11.
To prevent this to happen, let's get the root coordinate from the xembed
and let's use it to compute the synthetic event root x/y.
We could have even used the actual event position for this, but getting
it from the xembed makes this more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3283>
The format of the .desktop file names and their StartupWMClass of
Chromium and Chrome shortcuts has changed, so update the docs to match
the most recent versions of these web browsers.
The user interface to create shortcuts has also changed. They are no
longer created through a "Tools" menu (which doesn't exist anymore), but
rather through a "Save and share" menu. So add that to the docs as well.
Finally, replace the examples using the GNOME Wiki with examples using
the new GNOME Developer Handbook.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7482
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3289>
Simply looking at the return value of sd_pid_get_user_unit can be used
to determine if the process is in a systemd unit, but it doesn't say if
gnome-shell is managed by systemd.
For example, running toolbx on a host with systemd creates a libpod
unit, even if the gnome-shell that gets started in the toolbx is itself
not managed by systemd.
We can make sure that gnome-shell is managed by systemd simply by
checking if the unit we're running starts with org.gnome.Shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3267>
meta_selection_source_memory_new previously had some precondition checks
which would return NULL if the mimetype is NULL but now that it returns
an error we can't do that anymore.
Move the precondition checks to the caller instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3260>
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>
