When removing a string from a settings list, we iterate over all
existing entries and copy all strings except the one that's being
removed to a new list, which is then written to GSettings.
However we currently always increment the index, so we end up with
a NULL entry in place of the removed entry, which is then interpreted
as the end of the list. In other words, we also remove all entries
that follow the removed string.
Fix this by looping over the list entries instead of the index, and
only increment the index for entries we copy.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1946
Instead of every individual StThemeNode. There are essentially two kinds
of theme nodes: Those we create for lookups, and those interned by the
theme context and used by StWidgets. Listening to the signal on the former
is pointless as they are short lived and not meant to be really used for
drawing. So it is only essential to track stylesheet changes in those we
intern for later use.
This change does precisely that, it lets the StThemeContext track the
stylesheet changes and let all known theme nodes reset their state for
it.
The internal array holding all connected handlers for this signal in glib
was about the biggest single allocation made in gnome-shell, as interned
theme nodes nodes are around the 4 to 5 digit numbers. This essentially
makes it disappear.
This however means that widgets that are explicitly set a theme through
st_widget_set_theme() don't get their theme node implicitly updated.
There's little reasons to use that API, so perhaps this is an acceptable
tradeoff.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
A StWidget could get its style from a) a theme set in the StThemeContext,
and b) directly through it's ::theme property. Generally, overriding CSS
through the latter cannot be recommended as it loses any connection with
the global theme (eg. the ones you get through selector specificity).
It sounds a bit too powerful and pervasive, there's no use for it in
gnome-shell and doesn't look like something that could be recommended on
extensions. So, just drop this piece of API.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
By now, all containers and layout managers except StBin (and its
subclasses) use the generic ClutterActor expand/align properties
to control how their children are laid out.
This is particularly confusing as two or the properties StBin uses
for layout - x-align and y-align - shadow the generic ClutterActor
ones, but work very differently: They use a different enum and
determine how the bin lays out its child, instead of how the bin
is laid out by its parent.
Address this by deprecating the StBin properties and using the same
generic ClutterActor properties as everyone else.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/803
As per GNOME/mutter!385 [1], the compositor is finalized an its pointer
cleared on display close.
However, since the shell reacts to such events instead of controlling them,
when the shell is stopping or restarting and its display closing, the shell
stage destroys its children after the display closing is finished and during
this process the focus is unset, causing focus_actor_changed() to be called
and thus calls to meta_stage_is_focused() which deferences the now NULL
compositor, leading to a crash on shutdown.
Since after this point we should just ignore any stage event, disconnect
from them all.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/385https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/746
If graphical applications want to start from systemd units, they need to
start after we're properly ready to display them. This is particularly
important under X where `_GTK_FRAME_EXTENTS` and other xprops are needed
to have the right theming.
We're doing this in an idle callback so that the dynamic starting of
`gnome-session-x11-service.target` (which launches `gsd-xsettings`) as
the result of a signal emission happens before us signalling we're ready
for later things to start.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/750
Until commit 506b75fc7f we got away with not handling a NULL return
value, as cairo_surface_destroy() deals with a NULL surface; the same
isn't true for get_width/get_height, so guard to code in question to
prevent a crash.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1678
This is now handled in Mutter. Also, respect the result size instead
of assuming it to be equal to the clip size, as the clip takes actor
coordinates while the result takes buffer coordinates.
This can be fixed in a future API iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/728
We allow opening new windows as a fallback in case the app doesn't give
us explicit information about it, but we don't want to allow opening new
windows if we're unable to ask for this information (we can only use the
APIs to get this information while the app is RUNNING).
So always return FALSE in case the app is STARTING, always return TRUE
in case the app is STOPPED (starting an app always opens a new window)
and go through the usual checks in case the app is RUNNING (and
eventually fall back to FALSE).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
The use of box-shadow on a StWidget that has a background-gradient was
not been rendered correctly, the shadow borders was calculated inside
the st_theme_node_prerender_shadow function and in the case that we've a
prerendered_texture the max_borders was not calculated and are 0.
This patch creates a new static function to compute shadow maximum
borders copying the code from st_theme_node_prerender_shadow, and call
this new method in the case that we've a prerendered_texture.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1186
Evolution draws in libsoup, which exposes deprecated types in its
API. While its headers have been fixed to guard the affected symbols,
those fixes aren't in our CI images yet.
Until we get a fixed version, just disable all deprecation warnings
during the include in order to not trip over "foreign" bugs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We aren't using any deprecated evolution-data-server API, so we can
turn it off; this avoids compiler warnings for glib deprecations
used by those functions, which makes it harder to spot warnings for
our own code base.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We translate the raw stream content far too directly into a char*,
it notably forgets that the stream does not have nul-ended data,
this means we are potentially adding garbage after the pasted content.
Tentatively fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1570
An Endless OS system was found in the wild with a malformed
.local/share/gnome-shell/notifications. When deserialized in Python,
after passing trusted=True to g_variant_new_from_bytes(), the first
element of the first struct in the array looks like this:
In [41]: _38.get_child_value(0).get_child_value(0)
Out[41]: GLib.Variant('s', '\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff')
When deserialised in GJS, we get:
gjs> v.get_child_value(0).get_child_value(0)
[object variant of type "s"]
gjs> v.get_child_value(0).get_child_value(0).get_string()
typein:43:1 malformed UTF-8 character sequence at offset 0
@typein:43:1
@<stdin>:1:34
While g_variant_new_from_bytes() doesn't have much to say about its
'trusted' parameter, g_variant_new_from_data() does:
> If data is trusted to be serialised data in normal form then trusted
> should be TRUE. This applies to serialised data created within this
> process or read from a trusted location on the disk (such as a file
> installed in /usr/lib alongside your application). You should set
> trusted to FALSE if data is read from the network, a file in the
> user's home directory, etc.
Persistent state is read from the user's home directory, so it should
not be trusted. With trusted=False, the string value above comes out as
"".
I don't have an explanation for how this file ended up being malformed.
I also don't have an explanation for when this started crashing: my
guess is that recent GJS became stricter about validating UTF-8 but I
could be wrong!
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1552
Instead of going via the MetaShapedTexture to get the cairo surface, get
it from the window actor. The window actor can then handle this in a way
that makes it include potential subsurfaces.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/692
Using the bus name to notify service startup to systemd has some
disadvantages. The main one being that systemd will consider a
gnome-shell restart (Alt+F2 r) a service failure and restart the shell,
cleaning up all its children (i.e. user launched applications). In the
future the shell should launch applications in their own transient unit
so that a service restart does not affect applications.
Another potential issue is that we must never load
gnome-shell-wayland.service and gnome-shell-x11.service at the same
time, as systemd does not like two services providing the same bus
name.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1496https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/690
Mutter's Clutter fork can no longer be initialized separatedly, as
its backend now draws from MetaBackend. Adjust the code to use the
newly added test initialization function instead to get the test
back up.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Clutter's backend code depends on MetaBackend now, which makes it
impossible to initialize without resorting to private mutter API.
Luckily we only need Clutter for interactive tests which are broken
anyway, as Clutter.main() and friends were removed a while ago.
So for now, get at least unit tests working again by simply the
unnecessary Clutter initialization.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Popups and other override-redirect windows are meaningless to everything
that depends on the ShellWindowTracker. Ignoring those windows will result
in less ShellApp::windows-changed signal emissions, and less activity in
the AppMenuButton and everything else that depends on them.
Reduces gnome-shell CPU activity while typing on the Epiphany addressbar,
as the pop up animation there results in a number of xdg_popup being
created and destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/642https://gitlab.gnome.org/GNOME/mutter/issues/556
