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
Replace the usage of IconGrid in the grid search results by
a custom layout manager that only allocates as many children
as the actor can fit.
This new layout manager does not implement changing the icon
size depending on the screen size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1265
This is a small convenience method for using ClutterActor's iterator API
with javascript's built-in iterator protocol, for example as:
for (let child of container.iterate_children())
doStuff(child);
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1268
For fd.o notifications, we are taking the sender's PID into
account when associating notifications with sources (mainly
to deal with notify-send).
This broke when the implementation under the well-known name
was moved into a separate service, as the implementation in
gnome-shell will now always see the public notification-daemon
as sender.
Restore the old behavior by resolving the sender PID in the
separate service, and pass it as hint to the implementation
in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2592
Spidermonkey caches imports, which means that uninstalling an
old extension version and installing a new one doesn't work as
expected: If the previous version was loaded, then its code will
be imported instead.
For the last couple of releases this has been a reliable source
of extension bug reports after major GNOME updates. Thankfully
chrome-gnome-shell removed its update support in favor of our
built-in support now, but users may still use older versions
or perform those actions manually, so it still makes sense to
catch this case and set an appropriate error.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1248
The do-not-disturb button and the contained switch are
tied together via a bidirectional property binding.
However it still matters which objects are used as source
and target, as that will determine the initial state: Right
now the (unchecked) button is used as source, which means
that do-not-disturb is turned off on startup.
We want the state to be preserved, so swap source and target
to let the switch (that is bound to the underlying GSetting)
control the initial state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2804
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
Whether or not an extension has errors influences the 'canChange'
property, but so far we only update it for errors that occur when
initializing the extension, not when an extension is enabled later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1249
Soup.SessionAsync by default sets timeout and idle_timeout to 0. This
causes connections to hang around in state CLOSE_WAIT forever after the
remote host has closed the connection.
To fix this, we could set timeout and idle_timeout manually. However,
Soup.SessionAsync is marked as deprecated anyway and should be replaced
by Soup.Session. Doing so also sets a default timeout of 60 seconds.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2774
Removing a stylesheet from the theme will trigger a style update. There's
little point in updating the extension actors that are about to be destroyed
(hopefully), so call the extension's disable() function first.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
Sometimes an MPRIS media player will create and then destroy an object
before the signals that handle the object's destruction can be created.
This verifies that the object still exists after the necessary signals
have been created.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2776
Since commit 0ecddafc20 gsd-xsettings startup has been made conditional
on the systemd user instance being available at runtime. While that is
correct, it means that completing xwayland startup is also conditional
now.
We always want xwayland startup to go ahead, so wait for the XSettings
plugin to appear on the bus when gsd-xsettings is launched by gnome-session
and complete the task immediately if startup fails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1252
Changing the icon to 'system-log-out-symbolic' has no visual
change in a default GNOME setup since both 'system-log-out-symbolic'
and 'application-exit-symbolic' are the same in adwaita-icon-theme
(at the time of writing), however, other icon themes differentiate
between the two icons so pointing to the appropriate icon name
is the right thing to do.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2751
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
