We sometimes return custom D-Bus errors. Right now those errors
are ad-hoc, which means receivers don't have a proper way of
checking whether a thrown GLib.Error corresponds to a particular
remote error.
In order to change that, we should define proper error enums and
domains, and register them with GDBus, so that there is an automatic
mapping between D-Bus errors and GLib.Errors.
The new module doesn't export any domains or enums yet, but provides
internal tooling to make these exports more convenient.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
Returning a GLib.Error from a method invocation will encode the
error when sent over the wire. In case the error itself is already
an encoded remote error, just passing it on will result in double
wrapping.
Avoid that by stripping any remote error information before
returning it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
This object contains only the `title` and `icon` of a
`MessageTray.Source` which allows using it for sources
that aren't notification sources like mpris.
The old `MessageTray.Source` isn't renamed to something
less generic to not break API. Once we have a good reason
we should rename it to something more specific.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
Even though the comment in the code says that sources are reused even
thought the app title has changed this is actually not the case. Therefore
when ever the app title of a notification changes a new `Source` is
created. Therefore there is no point in setting the app title again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
As the notification redesign affects the API anyway, we can just
as well use the opportunity to modernize the code.
Turning the icon into a GObject property means we no longer need
a custom signal for change notifications, and the icon becomes
usable in bindings.
Since setting an `GThemedIcon` is common this also adds a convenience
property to set the icon name directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
They use API from Clutter.Rectangle which hasn't been used in the
magnifier since commit c815979f, and has since been removed from
Clutter altogether.
Since the methods are unused, remove them instead of fixing them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2037>
If something grabs the key focus while a modal is pushed, keeping
key-focus on that actor seems like the smarter thing to do than setting
it back to the last focus after the modal gets popped again. So check if
the key focus actor that we set when pushing the modal got changed when
popping that modal, and if it got changed, simply don't touch key focus.
This fixes a bug with the close dialog, where key focus isn't correctly
set to the dialog after alt-tabbing to a window showing a close dialog.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
Now that StIcon updates its texture automatically on icon theme
changes, we only have to recreate icon actors that aren't StIcons.
(This probably only applies to the folder icon in the app grid
where the sub-icons do use St.Icon, but making that assumption
feels dodgy with an API as generic as `createIcon()`)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
Since commit a4660293748, the activities button uses the standard
`:checked` pseudo class in the overview instead of the custom
`:overview`.
As a side effect, the generic handling of the `CHECKED` Atk state
in StWidget now covers the case, and we no longer need to manage
the state explicitly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3126>
Enables the use of a new `xkb-model` dconf key to let user configure
their desired keyboard model.
Also included is additional glue for respecting X11Model set at the
system level (ie. via `localectl`).
For simplicity, this assumes the use of one global keyboard model.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2583>
On wayland, transient windows don't use the DIALOG window type,
so any effects that special-case dialogs currently pick the
wrong animation.
Fix that with an "animation window type" that is used instead
of the real type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3125>
The indicators are currently part of the background image in the
high contrast theme. Using symbolic icons instead allows separating
the switch shapes from the high-contrast setting in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3107>
The values of the two control widgets are syncronized, meaning
that both emit signals when the local value changes, regardless
which one is visible and is actually used by the user.
This is not ideal because it leads to two dbus calls
per local change. To alleviate this, only consider
changes from the widget that is visible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
The logic could enter an infinite loop because it tried to
propagate local changes to g-s-d that were caused by signals sent
by g-s-d. For example:
1. slider is set to 50
2. Set(50) dbus call is sent
3. slider is set to 51
4. Set(51) dbus call is sent
5. PropertiesChanged arrives due to Set(50)
6. this._sliderItem.value is set to 50
7. notify::value is emitted from this._sliderItem
8. Set(50) dbus call is sent
9. PropertiesChanged arrives due to Set(51)
10. this._sliderItem.value is set to 51
11. notify::value is emitted from this._sliderItem
12. Set(51) dbus call is sent
To alleviate this issue, block signal handlers when the local state is
changed due to a remote event.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7111
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
Our telepathy component has been optional for years, and it is
disabled by default on major distros, so we cannot assume that
it handles any particular notifications.
Plus Empathy itself is mostly dead, so it's unlikely to be used
much anymore anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3110>
All the ControlsManagerLayout uses from BoxLayout is the spacing
property, both size requests and allocation are completely custom.
That makes subclassing really questionable, so stop doing that
and just hook up to the `spacing` style property manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3104>
