The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
While the gsetting is available for all who needs it, the Shell might
override it given various hueristics. Expose the decision made by the
Shell via a new property.
Intended to be used by gsd-xsettings as well as xdg-desktop-portal-gtk.
This also add a version property to the API, so that semi external
services (xdg-desktop-portal-gtk) can detect what API is expected to be
present.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/757
Clocks has exactly the same issue as Weather: Its integration currently
relies on accessing its settings directly, which isn't possible when
the app is sandboxed.
Fix this the same way we did for Weather, by adding our own setting
and syncing it with the app via a custom D-Bus interface.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
Our current Weather integration depends on poking around the app's
settings, which we cannot do when the app is sandboxed (as its
filesystem is "hidden away" in a container in that case).
So instead, use our own GSettings schema for the settings, and sync
it with GNOME Weather via a custom D-Bus interface.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1158
The existing 'ExtensionStatusChanged' signal has a fixed set of parameters,
which means we cannot add additional state without an API break. Deprecate
it in favor of a new 'ExtensionStateChanged' signal which addresses this
issue by taking the full serialized extension as parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
Extensions are currently enabled or disabled by directly changing the
list in the 'enabled-extensions' GSettings key. As we will soon add
an overriding 'disabled-extensions' key as well, it makes sense to
offer explicit API for enabling/disabling to avoid duplicating the
logic.
For the corresponding D-Bus API, the methods were even mentioned in
the GSettings schema, albeit unimplemented until now.
https://bugzilla.gnome.org/show_bug.cgi?id=789852
This API has been broken for quite some time now as the corresponding
mutter function meta_monitor_manager_get_monitor_for_output was removed.
If anyone tries to use it, we would just run into a backtrace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/490
While it is possible to register accelerators in-bulk, there is no
proper way to unregister them again. This adds the corresponding call
for UngrabAccelerator to allow ungrabbing multiple accelerators at the
same time.
The idea is that g-s-d can use this in the future to simplify the
keybinding reload logic.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/429
Here's a template string with '/' that escaped commit 94423151b2,
resulting in an xgettext warning when generating the .pot file.
Simply move it into the resource like the other interface descriptions
to make xgettext happy again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/407
The `GetWindows` method gives access to the list of windows for each
application with some of their properties, so utilities such as dogtail
can pick the window of their choice to interfere with using the provided
window id.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/326
Add a D-Bus API that allows the API user to introspect the application
state of the shell. Currently the only exposed information is list of
running applications and which one is active (i.e. has focus).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/326
We'll soon move the inlined XML of all interfaces we export or consume into
separate files. That's a significant increase from the interfaces for which
we install documentation, so it makes sense to use a dedicated subdir.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/537
