`mallinfo` has been deprecated in favor of `mallinfo2`:
```
The fields of the mallinfo structure that is returned by the
older mallinfo() function are typed as int. However, because
some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1786>
Until now, the absence of a `background-color` would cause `box-shadow`s
to be invisible. That was a bug because `box-shadow` is meant to be either
the color specified in `box-shadow`, or if none was specified then the
foreground `color`.
There is nothing in the spec that says the `box-shadow` rendering should
depend on `background-color`, so separate them. This ensures `box-shadow`
is rendered even when `background-color` is absent or transparent.
https://www.w3.org/TR/css-backgrounds-3/#box-shadow
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
From [the spec](https://www.w3.org/TR/css-backgrounds-3/#shadow-blur):
> the resulting shadow must approximate (with each pixel being within 5%
> of its expected value) the image that would be generated by applying to
> the shadow a Gaussian blur with a standard deviation [sigma] equal to
> half the blur radius
This does not change the value of `sigma`, it only corrects the value of
`sampling_radius` used to size the shadow texture. Since the texture is
no longer being slightly oversized it won't get scaled down when rendered
according to the dimensions provided by `st_shadow_get_box` in
`_st_paint_shadow_with_opacity`.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4409
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
Having an inaccurate paint volume didn't matter until ae338af1e8, but
after that having too small a paint volume resulted in apparent clipping.
Not because `clip_to_allocation` is set, but because the offscreen
framebuffer is sized to fit the paint volume only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
When a GTK app is started, we create a corresponding GtkApplication
proxy to monitor the app's busy state. If the app is stopped before
the proxy request finishes, we cancel the cancellable before clearing
the running state.
Usually we clear the cancellable once it is no longer needed, namely
when we got the proxy. However when the request was cancelled, the
cancellable has already been cleared, and if there's a cancellable,
it belongs to another request (because the window was added again,
for example when moving between monitors).
Leave that cancellable alone in that case, so we can cancel the
second request as well if necessary to avoid a crash when trying
to set the proxy on a cleared running state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1885>
Not when the main actor dimensions change. So now the shadows don't get
constantly regenerated during the overview animation. In my case this
reduces the render time of the overview animation (tapping Super) by
approximately 10% with 2 windows, or 20% with 10 windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1869>
app_notify_events_added uses an intermediate builder to construct an
array that is then added to the main variant using g_variant_builder_add
which should clear the intermediate, but doesn't due to the way it is
passed: by value, rather than as a pointer.
This was debugged with the help of Eduardo Habkost, who believes it
works on x86 due to big structs being passed as pointers.
Fixed: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3440
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1848>
We do notify on the ::pressed property after touch begin/end and
recording the event sequence, but we do not return the correct value
if the button was triggered via touch.
Consider the event sequence also in the ::pressed getter, so the
button is considered pressed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
Since commit f60a469a34, everything outside the fade area is painted
fully transparent. That is required for the fade effect during app
grid navigation, to prevent unfaded parts of surrounding pages
becoming visible on wide-screen displays.
However in most other cases, that behavior is the exact opposite
of what we want: Elements outside the fade area (like scroll bars)
should never fade.
In order to fix the regular case, hide the new behavior behind a
property.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4234
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1831>
With commits fab39bbea5 and
62e40a1350 we started depending on a new
ClutterActor API: clutter_actor_invalidate_paint_volume()
Given that this commit was applied to the 40 stable release, it broke
ABI compatibility with mutter, which is something we guarantee between
stable releases. So use GModule to dynamically find the symbol in our
loaded libraries. If it exists, use it and invalidate the paint volume.
If it doesn't exist, libmutter is still at version 40.0 and we don't
need to invalidate the paint volume.
This also adds a dependency on gmodule. We need to link against gmodule
to use g_module_open() and g_module_symbol() APIs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1807>
StWidget is overriding ClutterActors get_paint_volume() vfunc to adjust
for overpaint of things like box shadows that get set in CSS, it does
that by setting the paint volume to the theme nodes paint box.
Since StWidget can't really get notified when the paint box changes, we
just invalidate the paint volume when the theme nodes paint_equal()
returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
Since StViewport uses the value of the StAdjustment to create its custom
paint volume, ClutterActors newly introduced proper caching of paint
volumes doesn't get notifed about changes to that paint volume and will
simply reuse the cached old one.
So make use of the newly introduced
clutter_actor_invalidate_paint_volume() method to make sure ClutterActor
will ask for the paint volume again on the next paint.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
Since commit 770231, StImageContent implements the GIcon interface, which
allowed us to represent all application icons as GIcon (app-info, X11 icon
property or themed fallback icon).
While that change made for a nicer ShellApp API, it did introduce a
conceptual issue in st_texture_cache_bind_cairo_surface_property():
GIcons usually represent static icons, while the ClutterContent
returned by that method updates automatically when the bound property
changes.
Address this by tracking the MetaWindow:icon property in ShellApp, and
update the fallback icon when it changes. With that, a GIcon object
always represents the same icon, and any icon change is reflected
by a corresponding GIcon change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
We hold a reference to all windows we track for the app. While that
reference is unlikely to be the last remaining one, we still shouldn't
release it until we are done with the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1751>
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.
This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.
We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.
In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This reverts commit 87558efbf1.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.
Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3833
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1745>
Launching applications on a particular workspace works through
launch contexts and startup notifications. While this is no
longer required by a launcher/WM split, in theory this allows
us to reliably identify the correct window to apply startup
properties to.
However in practice we fail more often than not: Missing support in
toolkits, differences between display protocols, D-Bus activation
and single-instance applications all provide their own pitfalls.
So instead, take advantage of the fact that launcher and WM live in
the same process, and go with the unsophisticated approach: Just
remember the last workspace that was requested when launching an
app, then move the next window that is associated with the app to
that workspace.
This will break X11 applications that set an initial workspace, but
that's legacy functionality anyway (given that there's no wayland
protocol for that functionality), and seems a price worth paying
for making launching apps on workspaces more reliable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1316>
This will be needed for fine tuning of the visible area for appGrid
navigation purposes. We most nominally can let it happen via CSS as
the size calculations happen on size allocate, so we want to avoid
triggering relayouts while adapting to the given size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This property controls whether the viewport clips the content to its own
allocation or not. This will be necessary in special modes that we want to
render past the viewport inside a scrollview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When we're painting off-stage, for example because we're screencasting
or taking a screenshot, there won't be a stage-view associated with the
paint context. The BlurEffect previously didn't handle that case and
would crash.
Fix that and handle that case by assuming the scale is 1 and not
offsetting the rectangle we blit from the draw framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1673>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
Commit 473e77e2c5 fixed applying the :insensitive pseudo class to
initially unreactive widgets, and adjusted the style test to work
with that.
In hindsight, we can do better than just making the test work, and
include a test case for the :insensitive styling as well (namely
the issue the previous commit was fixing).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1649>
We are applying the :insensitive pseudo class to unreactive widgets,
or at least we are supposed to. As we currently only update the style
on notify, we don't apply it to initially unreactive widgets.
This was covered up partially until recently when Clutter started to
use G_PARAM_EXPLICIT_NOTIFY. Before that, the notify handler would run
when explicitly setting :reactive to FALSE at construction time.
Make sure we always apply the pseudo class correctly by updating it
after construct properties have been set.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3685
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1648>
We want to use the fast path of filling the entire area if either the
left and right shadows would overlap or the top and bottom shadows. The
latter check was wrong due to a typo resulting in the regular path
being used in some cases it couldn't (and shouldn't) handle.
This was causing the inset shadow used to highlight panel buttons to
not appear for buttons above a certain width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1646>
The shader code currently only accounts for padding for the
bottom and right fades, but not for top and left.
As a result, we only fade the right edge when swiping through app
picker pages, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1569>
Turns out that shell_screenshot_screenshot_area was affected
by the same issue that shell_screenshot_screenshot used to have.
Adapting code changes from commit id c09be8b0:
"screenshot: Grab screenshot during paint on X11" fixes it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1549>
While most secrets are serialized as individual settings with a string
value, all VPN secrets are serialized together as a string dict which is
the value of a single setting. Incorrect serialization causes VPN
secrets to not be remembered by NetworkManager.
This commit adds a new method that allows adding secrets as VPN secrets
specifically such that they can be correctly serialized.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1535>
What the blur shader does is going n_steps in each direction (e.g. in case
we're in the horizontal pass that means left and right direction), sampling
the adjacent texels of the texel we're currently blurring. That means
n_steps actually is the amount of texels we're sampling in one direction,
not in both directions.
Make n_steps match what the blur shader does, and rename it to sampling_radius
to match what it really means. Do that for both st-theme-node-drawing.c and
st-private.c
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1542>
This new ClutterOffscreenEffect vastly simplifies subclasses
by allowing them to hand the parent class a CoglPipeline to
use.
Override the create_pipeline() vfunc and return the (cached)
pipeline. Remove the paint_target() override and the now
unnecessary texture size fields from the structure.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1350>
We might not be able to directly paint the stage to an offscreen, if
there currently is a fullscreen unredirected window. To make it possible
to take a screenshot in this situation, disable unredirecting, queue a
frame, and take a screenshot after having painted that frame, before we
go back being unredirected.
Don't do this on Wayland because it's a waste.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1453
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1534>
With ClutterBlurNode available, we can remove our own implementation
and delegate the blur shader and framebuffers. This simply replaces
the pair of layer nodes (vblur and hblur) with a ClutterBlurNode,
and removes all dead code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1528>
Port the blur effect to the new ClutterEffect.paint_node() vfunc.
Update the function names to match what they do, e.g. "apply_blur()"
now creates the blur subtree and thus was appropriately renamed to
"create_blur_nodes()".
There are 3 subtrees that can be generated by the blur effect:
1. Actor mode (full subtree; no cache)
Root
|
|
Layer (brightness)
|
Layer (horizontal blur)
|
Layer (vertical blur)
|
Layer (actor)
|
Transform (downscale)
|
Actor
2. Actor mode (partial subtree; cached contents)
Root
|
Pipeline
(final result)
3. Background mode
Root
|-----------------------
| |
Layer (brightness) Actor
|
Layer (horizontal blur)
|
Layer (vertical blur)
|
Layer (background)
|
Blit
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1339>
Screen magnification is the compositor's business, not that of "random"
unprivileged tools. And for cases where a more specialised behavior is
wanted, an extension likely does a better job than a consumer of the
D-Bus API.
In addition to that, exporting the interface has been broken for an
unknown time, because the object that holds the implementation isn't
referenced and thus ends up being garbage collected, whoops.
And last but not least, this gets rid of the last public D-Bus name
that isn't clearly in the system namespace (org.gnome.Shell,
org.gnome.Mutter, org.gtk).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3452
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1523>
This is a relict from the pre-3.0 days, when it was common to
replace a running GNOME 2 session with gnome-shell. There has
been no good reason to claim the name for many years, time to
drop it.
If someone really wants to run gnome-panel alongside the shell,
they probably know what they are doing. Or cannot be helped anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1521>
In some styles the top or left sections of box-shadows would go missing
even though they had non-zero thickness. This was because the inner
local coordinates could become very slightly negative and were then
incorrectly judged to be invisible.
Negative coordinates should not be ignored because that's where the
entire top/left sections of shadow are meant to exist. It's only the
sections of shadow with zero thickness that we should skip.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1417>
Not checking for this would result in `clutter_actor_add_child`
failing, but StBin keeping a copy in `priv->child`. So later on,
`st_bin_remove` would never be called on it and this assertion
would fail and crash the whole shell:
```
static void
st_bin_destroy (ClutterActor *actor)
{
StBinPrivate *priv = st_bin_get_instance_private (ST_BIN (actor));
if (priv->child)
clutter_actor_destroy (priv->child);
g_assert (priv->child == NULL);
```
By disallowing spurious `st_bin_set_child` calls we now prevent StBin
from entering such a corrupt state and the above assertion won't fail
anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1507>
Just like the internal ClutterText, the icon actors are part of the
entry. It therefore makes sense for the icons to not react to clicks
when the entry itself is non-reactive; again, just like the text.
That behavior is also consistent with icons in GTK entries.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3138
Like `GtkAdjustment`, `StAdjustment:changed` is not emitted for the
`value` property except when changed with `st_adjustment_set_values()`.
Note this behaviour in the signal documentation
closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/3147
(optional) is only valid for (out) or (inout) parameters (that are
marked as such).
However GError** arguments appear as throws="1" in the GIR anyway
instead of an explicit parameter, so we don't need any annotation
at all here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1408
Much of St is undocumented, aside from input/output arguments. This is
no doubt because a lot of it parallels Gtk closely, but is worth
improving since many new programmers are not familiar with Gtk.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2983
This eliminates the need to wait for redraws, drawing cursors, and
stiching together cairo images in case the screenshot covers multiple
monitors.
All of that is now handled by mutter itself.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1383
The framebuffer we use for rendering shadows is scaled by the resource
scale, that means we also need to offset coordinates when translating
them to the framebuffers coordinate system.
So far we forgot to do that when translating the framebuffer using the
position of the actor, which lead to small rendering bugs of
text-shadows for actors allocated at non-zero origins. To fix that,
simply multiply those positions with the actors resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1390
To do this, we now wait for the start/stop job to complete. We also have
two targets in gnome-session to ensure that everything is working as
expected.
In order to start the services, we simply request the
gnome-session-x11-services-ready.target unit, and wait for it to become
available. To stop, we use the gnome-session-x11-services.target unit
which should stop all services in a way that is entirely race free.
This requires both gnome-session and gnome-settings-daemon changes to
work (which are in the corresponding merge requests).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Move the screencasting into a separate D-Bus service process, using
PipeWire instead of Clutter API. The service is implemented in
Javascript using the dbusService.js helper, and implements the same API
as was done by screencast.js and the corresponding C code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
When using the NVIDIA driver, textures tend to loose their pixels when
suspending. In the past we handled this by figuring out when the NVIDIA
driver was used, and reload the background whenever we noticed we
resumed from suspend.
This shouldn't be needed anymore after
https://gitlab.gnome.org/GNOME/mutter/merge_requests/600, as it should
handle this by listening to video-memory-purged signal. Thus remove our
special handling here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1358
Since commit b60836932 we only allow WM_CLASS matches for sandboxed
applications if the found app's ID is prefixed by the sandbox ID.
The existing check still has a hole in it though: "org.example.Foo"
and "org.example.FooDevel" are different applications, yet the former
is a prefix of the latter.
So tighten the check by including a trailing "." in the checked prefix;
this excludes cases like the above, while still working for the regular
case of a single .desktop file because our app IDs include the ".desktop"
suffix.
Spotted by wjt.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1357
Currently our heuristics for matching a window to its app check
for the application ID before the WM_CLASS, as the ID is more
reliable in so far that it is outside the application's control
and so it cannot use it to spoof a different application.
However this also prevents applications with multiple .desktop
files like LibreOffice from matching any .desktop files other
than the one under the main ID.
Since we now no longer allow the WM_CLASS to match a .desktop
file that doesn't belong to the sandboxed application, we can
fix that issue by checking the WM_CLASS first, without opening
the door to spoofing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
At least flatpak (no idea about snap, sorry) enforces that all .desktop
files exported by a sandboxed app use the application ID as prefix.
Add the same check when trying to find a match based on the WM_CLASS,
to prevent sandboxed apps from matching a .desktop file they do not
own.
At the moment this is unlikely as we check for a match on the
sandboxed app ID first, but we are about to change that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
Now that we can always associate a GIcon with the app, add a method
to access it. While create_icon_texture() is still likely to be more
convenient in most cases, exposing the icon can still be useful, for
example to add it to a different kind of actor or to compare it with
other GIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
We still load the surface into an StImageContent, but instead of
adding the content to an actor we hand out, return the content
itself (as GIcon).
That means we lose the ability to specify an icon size, but as we
get the pixel data from a fixed-size surface anyway, that shouldn't
matter much in practice.
Not to mention that the function is only used for fallback X11 icons,
which are already shit more often than not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
On the one hand, this is a bit of a stretch: StImageContent is what
we create from GIcons.
But on the other hand, there's some justification: StImageContent does
represent an image (and likely icon) after all, and there's some
precedent with GdkPixbuf.
In the end as we don't care about serialization or loading from other
API, we can go with a very crude implementation that allows us to
pass out a content as GIcon and use it directly when "loading" it.
We will use that soon to represent X11 window icons as GIcons, which
in turn will allow us to unify app icon handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
Instead of using the "notify::resource-scale" signal and StWidgets
"resource-scale-changed" signal, use the new "resource-scale-changed"
signal of ClutterActor, which replaces its "resource-scale" property.
Since we'd now have two "resource-scale-changed" signals, one on
ClutterActor and one on StWidget, remove the StWidget one in favour of
the new one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
When scrolled, the container's allocation is smaller than the allocation
of the content. To account for that, commit 2717ca9d08 added the
additional size reported by the layout manager to the content allocation.
However as it did so unconditionally, we now allow children to extend
outside the parent even when *not* scrolled, which breaks any constraints
set on the container (like "width" or "max-height").
Fix this by only extending the child allocation in scrollable dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2491
The performance of the icon grid was being hindered by a large number
of primitives (a few hundred) being copied from the CPU to the GPU on
each frame. This was first noticed in mutter#971 but we failed to
investigate all the issues at the time.
You can also see the high number using `COGL_DEBUG=batching` or
`COGL_DEBUG=disable-texturing`. So now it's obvious that high number is
every letter of every label being uploaded as a separate quad. Let's not
do that and instead treat the whole label as a single quad/texture.
Measured performance on an i7-7700 at UHD 3840x2160:
Journal entries per frame on the icon grid:
* Before: 288 (18 KB copied from CPU to GPU)
* After: 73 ( 4 KB copied from CPU to GPU)
Spring animation:
* Before: 20-30 FPS, avg 22/peak 45 milliseconds per frame
* After: 30-40 FPS, avg 14/peak 28 milliseconds per frame
Scrolling the icon grid:
* Before: 15 FPS, 50 milliseconds per frame
* After: 30 FPS, 28 milliseconds per frame
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1329
As the view now scrolls from right-to-left in RTL locales, the
scroll bar handle should reflect that.
Likewise the event handling needs adjusting as well: Scrolling
left should increase the adjustment value, and clicking the
trough to the left of the handle as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
clutter_text_get_selection() creates a copy of the selected text which
gets passed to st_clipboard_set_text() which creates its own copy. The
copy returned by clutter_text_get_selection() however never got free'd.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1306
The HasCalendar property reflects whether there are any views, and views
change either when clients appear/disappear or when the time range changes.
However we currently only emit the PropertiesChanged signal for the former,
fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1300
The shell mime sniffer goes through all the files in a directory,
however in case a file content type is not recognized, the GIO function
g_file_info_get_content_type() may return NULL, causing a crash when
looking up into the content type tables, as they are supposed to contain
strings only and they use `g_str_hash` has func, which doesn't support
NULL values.
So, in case we get an invalid content type, let's just ignore it,
without adding it to the cache as we do in the nautilus code that was
inspiring the sniffer.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2643
As outlined in commit 36b8dcbe07, we can end up with wrong icons
if the icon theme changes right after a GTK theme change to/from
HighContrast triggered a theme reload.
That's because when we reload icons for the new icon theme, there
are already pending requests due to the icon-style change; those
requests are simply re-used for the new icons, with the existing
icon infos from the old theme.
The above commit applied a simple work-around by changing the
icon theme before the GTK theme, but that only works for the
HighContrast switch in our own UI.
It turns out that Settings also uses the "wrong" order, so the
issue still reproduces with the Universal Access panel.
So instead of relying on everything changing the settings in the
order we expect, cancel all ongoing requests on icon-theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1277
Since the `MetaSelection` of the global `StClipboard` is private (and
should be), there is no reasonable way for extensions or external code
to query the supported mime-types.
Add `st_clipboard_get_mimetypes()` so this can be queried without
poking around in private code.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2819
Since e06109c23c we keep old theme nodes
valid during the emission of the "custom-stylesheets-changed" signal.
It turns out that we might still look up the file of a stylesheet using
the files_by_stylesheet hashtable during the emission of that signal,
causing a crash because the assertion in _st_theme_resolve_url() fails.
So fix that and remove the stylesheet entry from the files_by_stylesheet
hashtable after emitting the "custom-stylesheets-changed" signal. And to
be consistent, also remove the entry from the stylesheets_by_file
hashtable after emitting the signal.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
`StBoxLayout` has a couple properties (`vertical` and `pack-start`)
improperly referenced as signals, and is somewhat unclear these
properties are wrappers around the underlying `ClutterBoxLayout`
properties.
Fix these up and add references to the underlying properties, rather
than redescribing them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2816
Avoid starting/stopping the gsd-xsettings systemd unit if the shell itself
was not started via systemd. In the lack of a user session manager, we
have no means to neatly start/stop services, so should rely on the good
ol' gnome-session to do this for us.
This changes the return value meaning slightly, TRUE means "service did
start", FALSE otherwise. The error is only raised if we ought to start,
but it produced an error somehow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1238https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2755
Since we now remove all theme nodes on a stylesheet change (ie.
StTheme's "custom-stylesheets-changed" signal) instead of only
invalidating them, those nodes may not be accessed anymore as soon as
"custom-stylesheets-changed" is emitted.
It turned out though that when comparing them to the newly generated
nodes in `st_widget_recompute_style()` using the
`st_theme_node_paint/geometry_equal()` functions, the properties of the
old nodes will still be accessed, causing a crash since the
CRDeclarations are already freed.
To fix that, keep the reference to the CRStylesheet, which owns the
CRDeclarations used by the theme nodes, around a bit longer, so it's
still possible to access the CRDeclarations inside the
"custom-stylesheets-changed" signal handler. This allows us to compare
the old theme nodes to the new ones since the CSS properties of both are
still valid.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709
StThemeNodes are built around the assumption that they're "immutable",
that means they are created once with certain parameters (that resolve
to certain css properties) and then replaced with new ones in case those
parameters changed.
Changes to the internal information stored by theme nodes (i.e. the css
properties, font names or the cached scale-factor) are not all handled
the same though: For changes to the font or the scale-factor we remove
all theme nodes from the cache and let the widgets which are on stage
generate new theme nodes. For changes to the css properties/the
stylesheet, we invalidate the properties of all theme nodes but keep
them in the cache using `_st_theme_node_reset_for_stylesheet_change()`.
So be a bit more consistent and handle changes to the css-properties/the
stylesheet stored by StThemeNodes the same way as changes to the font or
scale-factor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1218
Theme node invalidation stops at unmapped widgets, and widgets
that forget to chain up to the default ::style-changed implementation.
This may leave stale nodes that were invalidated on
StThemeContext::changed, but are still set on widgets, and maybe
used for CSS property lookups.
Make sure that theme node invalidation happens always by moving
propagation outside the vfunc, and ensure the theme nodes are reset
across the full actor tree. Emission of ::style-changed, and obtaining
a new theme node may be delayed till when the actor is mapped.
The theme node is also cleared after unparenting an actor to avoid
stale references.
This ensures that all widgets get their theme node cleared after
stylesheet changes, instead of maybe being left with a theme node
that's been cleared of all its properties.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2541https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1223
Commit d76162c1c0 removed the ability to pass an extension UUID to
the Extensions app, when we moved the dialog to a portal and made
gnome-shell use it instead of spawning the extensions app.
However that missed that many extensions called out to the app to
open their own prefs.
While extensions are encouraged to switch to the new openPrefs()
convenience method added in commit 8030d9ad32, restore the old
behavior with a small script under the old gnome-shell-extension-prefs
name that either calls out to the portal or launches the app.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
I noticed the following warning while building the .deb package for
gnome-shell on Endless OS:
../src/st/test-theme.c: In function ‘main’:
../src/st/test-theme.c:549:3: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result [-Wunused-result]
chdir (cwd);
^~~~~~~~~~~
(Of course this is very unlikely to fail in practice.)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1208
We currently always ignore the minimum width of the hint actor and
request/allocate the preferred width. This can be problematic with
labels with long text, where we should rather ellipsize the text
than allow the entry to grow indefinively.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2607
When building the list of window PIDs, it's possible Mutter doesn't know
about the PID the client has and meta_window_get_pid() will return 0. We
should handle this case by not adding the PID to the list of PIDs
instead of adding an invalid one to it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
MetaWindows get_pid() API changed to use the client PID, which also
works for Wayland clients instead of only X11 clients now. This API
returns 0 instead of -1 for invalid PIDs, so update our check according
to that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
Just like StIcon does, we should use a container widget for the fallback
app icon that we get using the cairo surface property. It's needed
because the widget returned by shell_app_create_icon_texture() can be
resized freely, while we want the aspect ratio of the actual texture to
remain the same.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2578
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
The app-cache code currently stores the folder translations in a hash
that can be accessed via shell_util_get_translated_folder_name().
This hash uses the filename (inc. extension) for the "desktop-directory"
as key which causes an issue when trying to find the translation
on AppDisplay._findBestFolderName() which gets categories (folder names)
from the app info which doesn't contain the ".directory" extension.
Fix that by storing the filename without extension as the hash key for
the cached folder translations.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1168
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
We want to completely clear the background framebuffer when switching
back to ACTOR mode to make sure the `background_fb.framebuffer` check
will fail in `update_background_fbo` when switching to BACKGROUND mode
again. Otherwise the checks in `update_background_fbo` will return TRUE
and we will keep using the background framebuffer that was created
before switchig to ACTOR mode.
While at it, also clear the background framebuffer completely when
changing the actor to avoid the same issue here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
When blurring only the actor (ACTOR mode), we don't want to apply any
scale, it looks fine without using the resource scale and it also seems
like `clutter_actor_continue_paint` in `paint_actor_offscreen` only
draws an unscaled texture anyway (ie. if the resource scale is 2, only a
quarter of the framebuffer is being drawn to).
In BACKGROUND mode though, we need to scale the framebuffer using the
scale factor of the stage view (ie. the final scale factor for the
monitor) because the content of the framebuffer we blit is scaled using
that factor. Also, since the framebuffer we blit belongs to a stage view
and only includes the contents of this view, we need to adjust the
stage-coordinates of the actor to be relative to the stage-view.
To make sure we don't have to get the transformed actor size or position
multiple times during one paint-run and don't have to carefully floor()
or ceil() widths and positions, store the size of the actor (which is
also the size of the framebuffer) and its position relative to the stage
view inside a ClutterActorBox.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
A ClutterEffect is being painted as part of the paint cycle of
ClutterActor, where _clutter_effect_paint() is called before painting
the actual actor. With that, it's impossible that an effect gets painted
while it's disabled, so remove the check whether the ClutterActorMeta is
enabled before painting.
Also if everything works fine in Clutter, the ClutterActorMeta should
have an actor set and we've been notified about that actor in
shell_blur_effect_set_actor(), so assert that our cached actor is set
when painting the effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
The idea behind commit 3dd8ffc2bb to try harder to avoid empty
icon actors because of missing icons was sound, so implement that
behavior in StIcon itself:
If the main gicon was not found, and the fallback gicon isn't set or
wasn't found either, fall back to the standard 'missing-image' icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
The commit broke StIcon's :fallback-gicon property, as it relies on failure to load
an icon to determine that the fallback should be shown.
Luckily StIcon is the only user of st_texture_cache_load_gicon() (at least in
regular shell code), so we'll be able to implement the 'image-missing' fallback
there.
This reverts commit 3dd8ffc2bb.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
Add a small helper method to asynchronously "touch" a file and return
whether the file was created or not.
As g_file_make_directory_with_parents() doesn't have an async variant,
we need a C helper to make the entire operation non-blocking.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
Rely on the Pango renderer handling this properly, instead of tinting
the full ClutterText in the color specified through css.
Also set the caret color explicitly, since it used to be set as a side
effect of clutter_text_set_color(), but no longer is.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/850
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
If a given icon is not available for neither the current theme nor any
of the fallback options (default theme -"Adwaita", "gnome"...), the
call to gtk_icon_theme_lookup_by_gicon() will return a NULL value, which
returned by the Shell Toolkit as is, causing trouble in the Shell's JS
code when calling shell_app_create_icon_texture() to create an icon.
To at least mitigate the chances of this having this issue happening, we
should at least try to load the standad 'image-missing' icon from the
Icon Naming Specification spec when we receive a NULL here, so that
at least we try to show something to the user, even if it's ugly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1121
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
While we can use the libnm API directly from JS, the call will
synchronously load the VPN service descriptions from disk.
Previously we were lowering the impact by caching the result,
but as we stopped doing that, it becomes more important to address
the issue properly and move it off to a thread.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
For sandboxed apps, permission to talk to org.freedesktop.Notifications
looks innocent enough. However as all exported services share the same
connection to the session bus, that permission actually grants an app
access to *any* shell D-Bus API.
While we want apps to use the notification portal, it is still common
for apps to use libnotify, raw D-Bus calls or even notify-send.
We don't want to give those apps a way to circumvent most of the sandbox
restrictions, so stop owning the org.freedesktop.Notifications name.
In a next step we will implement a separate notification-daemon that
exposes the API on the well-known address and proxies any requests to
the real implementation in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
Commit 88ac339774 changed StEntry behavior so the text hint would
stay visible while focused, as long as the text buffer is empty.
However, IMs that use preedit still should count as "started typing",
while the text buffer is still officially empty.
To fix this, check on st_entry_update_hint_visibility() that there's
indeed no preedit buffer before showing the hint. We can't directly
listen to internal preedit buffer changes in ClutterText, so handle
preedit buffer updates through the ::cursor-changed signal that will
be indirectly emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1084
st_texture_cache_bind_weak_notify calls g_clear_signal_handler which
then calls st_texture_cache_free_bind. st_texture_cache_free_bind frees
the bind structure, so by the time g_clear_signal_handler tries to write
bind->notify_signal_id, bind has already been freed.
Fix this by using g_signal_handler_disconnect instead.
This partially reverts 135d178d08
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2334
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
Now that Xwayland startup is asynchronous, the function may be called
before X11 is available, resulting in a crash.
Fix this by only managing the tray immediately if we already have an
X11 display, and wait for it to be set up otherwise.
Likewise, unmanage the screen when X11 becomes unavailable.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
Since support for legacy status icons is implemented by extensions
nowadays, they need to undo the call to manage_screen() when they
are disabled.
Right now that means bypassing garbage collection with an explicit
call to run_dispose() on the Shell.TrayManager. That works, but is
rather ugly.
An explicit unmanage_screen() method is a nicer option, and will be
useful to us as well to deal with X11 going away (once Xwayland
crashes don't bring down the entire session).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
NaTrayManager in particular is deeply tied to X11. We currently assume
that X11 support is always available, but that is already not true
anymore - Xwayland startup is now asynchronous.
It will be even less true once we handle Xwayland crashes gracefully.
Start addressing that by not creating the corresponding resources once
and assume they exist for the lifetime of Shell.TrayManager, but make
sure they exist when actually needed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
The g_file_replace_contents_async() API can potentially call fsync() from
the thread calling into it upon completion. This can have disasterous
effects when run from the compositor main thread such as complete stalls.
This is a followup to 86a00b6872 which
assumed (like the rest of us) that the fsync() would be performed on the
thread that was doing the I/O operations.
You can verify this with an strace -e fsync and cause terminal to display
a command completed notification (eg: from a backdrop window).
This also fixes a lifecycle bug for the variant, as
g_file_replace_contents_async() does not copy the data during the operation
as that is the responsibility of the caller. Instead, we just use a GBytes
variant and reference the variant there.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1050
