dbusServices/extensions: Proxy Extensions API
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 03:02:28 +00:00
|
|
|
/* exported main */
|
|
|
|
|
Specify API versions for all public GIR APIs, except GLib
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
2022-04-04 10:26:43 +00:00
|
|
|
imports.gi.versions.Adw = '1';
|
2020-04-15 18:27:15 +00:00
|
|
|
imports.gi.versions.Gdk = '4.0';
|
|
|
|
imports.gi.versions.Gtk = '4.0';
|
2020-03-04 04:05:08 +00:00
|
|
|
|
2021-07-30 00:33:54 +00:00
|
|
|
const { Adw, GObject } = imports.gi;
|
2020-03-04 04:05:08 +00:00
|
|
|
const pkg = imports.package;
|
|
|
|
|
dbusServices/extensions: Proxy Extensions API
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 03:02:28 +00:00
|
|
|
const { DBusService } = imports.dbusService;
|
|
|
|
const { ExtensionsService } = imports.extensionsService;
|
|
|
|
|
|
|
|
function main() {
|
2021-07-30 00:33:54 +00:00
|
|
|
Adw.init();
|
2020-03-04 04:05:08 +00:00
|
|
|
pkg.initFormat();
|
|
|
|
|
2021-11-06 02:34:25 +00:00
|
|
|
GObject.gtypeNameBasedOnJSPath = true;
|
|
|
|
|
dbusServices/extensions: Proxy Extensions API
Similar to the previously added org.freedesktop.Notifications proxy,
this exposes the org.gnome.Shell.Extensions API and forwards any
request to the real implementation in gnome-shell.
The motivation differs though: We want to be able to package the
extension app as flatpak and distribute it separately, but the
extension prefs dialog is hard to impossible to sandbox:
- filenames need translating between host and sandbox, and we
can only do that in some cases (serializing/deserializing
extensions), but not others (extension settings that refer
to files)
- system extensions install their GSettings schemas in the system
path; the best we can do there is assume a host prefix of /usr
and set GSETTINGS_SCHEMA_DIR in the flatpak (eeks)
- extensions may rely on additional typelibs that are present on
the host (for example because gnome-shell itself depends on
them), but not inside the sandbox - unless we bundle all of
gnome-shell's dependencies
- if gjs/mozjs differ between host and sandbox, extensions must
handle different runtimes for the extension and its prefs
And all those issues occur despite a very permissive sandbox (full
host filesystem access, full dconf access, full org.gnome.Shell
access (including Eval()!)).
This new service will give us an alternative place for handling
the preference dialog:
- it runs outside of gnome-shell process, so can open windows
- it runs on the host, so the extension's prefs get to run
in the same namespace as the extension itself
That is, the service will provide portal-like functionality (albeit
not using the org.freedesktop.portal.* namespace, as extension
management is an inherently privileged operation).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 03:02:28 +00:00
|
|
|
const service = new DBusService(
|
|
|
|
'org.gnome.Shell.Extensions',
|
|
|
|
new ExtensionsService());
|
|
|
|
service.run();
|
|
|
|
}
|