gnome-shell/js/dbusServices/extensions/extensionsService.js

162 lines
5.2 KiB
JavaScript
Raw Normal View History

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-03 22:02:28 -05:00
// -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*-
/* exported ExtensionsService */
const { Gio, GLib, Shew } = imports.gi;
const ExtensionUtils = imports.misc.extensionUtils;
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-03 22:02:28 -05:00
const { loadInterfaceXML } = imports.misc.dbusUtils;
const { ExtensionPrefsDialog } = imports.extensionPrefsDialog;
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-03 22:02:28 -05:00
const { ServiceImplementation } = imports.dbusService;
const ExtensionsIface = loadInterfaceXML('org.gnome.Shell.Extensions');
const ExtensionsProxy = Gio.DBusProxy.makeProxyWrapper(ExtensionsIface);
var ExtensionsService = class extends ServiceImplementation {
constructor() {
super(ExtensionsIface, '/org/gnome/Shell/Extensions');
this._proxy = new ExtensionsProxy(Gio.DBus.session,
'org.gnome.Shell', '/org/gnome/Shell');
this._proxy.connectSignal('ExtensionStateChanged',
(proxy, sender, params) => {
this._dbusImpl.emit_signal('ExtensionStateChanged',
new GLib.Variant('(sa{sv})', params));
});
this._proxy.connect('g-properties-changed', () => {
this._dbusImpl.emit_property_changed('UserExtensionsEnabled',
new GLib.Variant('b', this._proxy.UserExtensionsEnabled));
});
}
get ShellVersion() {
return this._proxy.ShellVersion;
}
get UserExtensionsEnabled() {
return this._proxy.UserExtensionsEnabled;
}
set UserExtensionsEnabled(enable) {
this._proxy.UserExtensionsEnabled = enable;
}
async ListExtensionsAsync(params, invocation) {
try {
const res = await this._proxy.ListExtensionsAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(a{sa{sv}})', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async GetExtensionInfoAsync(params, invocation) {
try {
const res = await this._proxy.GetExtensionInfoAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(a{sv})', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async GetExtensionErrorsAsync(params, invocation) {
try {
const res = await this._proxy.GetExtensionErrorsAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(as)', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async InstallRemoteExtensionAsync(params, invocation) {
try {
const res = await this._proxy.InstallRemoteExtensionAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(s)', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async UninstallExtensionAsync(params, invocation) {
try {
const res = await this._proxy.UninstallExtensionAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(b)', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async EnableExtensionAsync(params, invocation) {
try {
const res = await this._proxy.EnableExtensionAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(b)', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async DisableExtensionAsync(params, invocation) {
try {
const res = await this._proxy.DisableExtensionAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(new GLib.Variant('(b)', res));
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
LaunchExtensionPrefsAsync([uuid], invocation) {
this.OpenExtensionPrefsAsync([uuid, '', {}], invocation);
}
async OpenExtensionPrefsAsync(params, invocation) {
const [uuid, parentWindow, options] = params;
try {
const [serialized] = await this._proxy.GetExtensionInfoAsync(uuid);
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-03 22:02:28 -05:00
if (this._prefsDialog)
throw new Error('Already showing a prefs dialog');
const extension = ExtensionUtils.deserializeExtension(serialized);
this._prefsDialog = new ExtensionPrefsDialog(extension);
this._prefsDialog.connect('realize', () => {
let externalWindow = null;
if (parentWindow)
externalWindow = Shew.ExternalWindow.new_from_handle(parentWindow);
if (externalWindow)
externalWindow.set_parent_of(this._prefsDialog.get_surface());
});
if (options.modal)
this._prefsDialog.modal = options.modal.get_boolean();
this._prefsDialog.connect('close-request', () => {
delete this._prefsDialog;
this.release();
return false;
});
this.hold();
this._prefsDialog.show();
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-03 22:02:28 -05:00
invocation.return_value(null);
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
async CheckForUpdatesAsync(params, invocation) {
try {
await this._proxy.CheckForUpdatesAsync(...params);
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-03 22:02:28 -05:00
invocation.return_value(null);
} catch (error) {
this._handleError(invocation, error);
}
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-03 22:02:28 -05:00
}
};