The current preference API - buildPrefsWidget() - predates client-side
decorations. While extension authors have been finding ways around
the limitation of not having access to the window/titlebar, the change
to the new Adwaita API seems like a good time for an updated API that
officially provides that access (as far as allowed by libadwaita).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
Adapt the new GNOME platform API for the upcoming 42. This makes
sure that we get the latest version of the stylesheet, as well as
support for the new dark mode.
Using the dedicated preference API also gives extensions with more
complex preferences an easier and standardized way for implementing
multi-page preferences.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
The error UI comprises the bits that are actually custom. Splitting them
out from the off-the-shelf window makes it easier to replace the dialog
with libadwaita's dedicated preference window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
Use GLib's spawn_async() instead of Gio.SubprocessLauncher() which does
not support the child setup function to start ibus-daemon.
This way we can restore the NOFILE limit prior to run the ibus-daemon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2117>
The REPLACE flag we currently pass is useless, as replacing the service
is disallowed when not started with the ALLOW_REPLACEMENT flag.
Fix this by adopting a more standard pattern where replacement is always
allowed, but only actually requested when `--replace` is passed on the
command line.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2152>
All fd.o Notifications signals are emitted for a particular notification,
so debugging aside, only the owner of said notification has a legitimate
reason to act on it.
So far we (and other implementations like the old notification-daemon)
have relied on the client-side to properly filter the signals (like
libnotify), but at least the QT implementation is known to not do
that.
Enforce correct client behavior by only emitting the signal to the
original sender.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5008
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2153>
- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
The calendar's timezone cache holds only timezones already received
or added to the calendar, thus when asking it for a timezone for "the first
time", it returns NULL and a wrong timezone is used instead.
The get_timezone() does not do any I/O when the timezone is already cached
on the client side, thus it's fine to use it.
This could exhibit with non-recurring events, which use custom time zones,
in which case the event is shown in a wrong time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2145>
CSS and JS adapted from the Overview window close buttons, but with some
style tweaks requested by the designers.
Since the screenshot UI is long-lived (it's created once at startup,
rather than every time it's opened), we need to refresh the close button
position, as it can change at runtime. Subscribing to preference changes
seems to be skipped for bindings generation in Mutter, but simply
refreshing upon opening the UI should do the job.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4997
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2147>
This was here exclusively to silence out events from other pointing
devices in the stage. Since ClutterGrab being used now is global to
all devices and events are coerced to an invisible actor, there is
no need to explicitly do this.
Also, this event handler was set on the stage, while the grab happened
on a child, so it was fairly uneffective already.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2146>
Since the grab no longer lets events bubble up to the stage unstopped,
we should be forwarding the key events that bubbled up to the dialog
to maybe cycle focus.
Fixes broken keyboard navigation in several context menus around the
shell, other than the panel ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
