isa/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
55cf8cf4bb
gnome-shell/js/dbusServices/org.gnome.Shell.Extensions.src.gresource.xml

22 lines
607 B
XML
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-04 03:02:28 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<gresources>
<gresource prefix="/org/gnome/Shell/Extensions/js">
<file>main.js</file>
<file>extensionsService.js</file>
dbusServices/extensions: Split out prefs dialog We're about to make changes to the UI, so this seems to be a good time to split GUI and service code. Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
2021-07-29 22:06:36 +00:00
<file>extensionPrefsDialog.js</file>
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
<file>dbusService.js</file>
extensionUtils: Split out extension convenience functions ExtensionUtils was originally used for shared functions between the extension system and the (old) prefs-tool, but then gained useful API meant for extensions themselves. It's a bit weird to mix the two, so split out the extension convenience API into a separate module. We will soon split up the module further, and add specific "flavors" for extensions and preferences, with the current code providing a shared base for both. That should explain both the new location and the odd module name. :-) Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
2023-06-30 10:57:41 +00:00
<file>extensions/sharedInternals.js</file>
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
<file>misc/config.js</file>
dbusServices/extensions: Take over prefs dialog from app As outlined earlier, in order to turn the Extensions app into a properly sandboxed application, we need to split out the extension prefs dialog and move it elsewhere. With "elsewhere" being the new Extensions D-Bus service, effectively turning it into a shell extensions portal. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 04:05:08 +00:00
<file>misc/extensionUtils.js</file>
dbusServices: Refactor service utilities from fileUtils into dbusUtils To enable porting services to ECMAScript modules independently of the shell, split DBus service utility functions into a new file, dbusUtils.js Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2365>
2022-07-05 07:25:02 +00:00
<file>misc/dbusUtils.js</file>
dbusServices/extensions: Include Params module It's unused and was removed in commit a0467bf875, which broke extensions that rely on it in their preference widget. As the removal only happened post-3.36.0, add it back until we branch. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2476
2020-03-24 09:13:43 +00:00
<file>misc/params.js</file>
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
</gresource>
dbusServices/extensions: Take over prefs dialog from app As outlined earlier, in order to turn the Extensions app into a properly sandboxed application, we need to split out the extension prefs dialog and move it elsewhere. With "elsewhere" being the new Extensions D-Bus service, effectively turning it into a shell extensions portal. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 04:05:08 +00:00
<gresource prefix="/org/gnome/Shell/Extensions">
<file>css/application.css</file>
dbusServices/extensions: Split error page from window 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>
2021-07-29 22:26:05 +00:00
<file>ui/extension-error-page.ui</file>
dbusServices/extensions: Take over prefs dialog from app As outlined earlier, in order to turn the Extensions app into a properly sandboxed application, we need to split out the extension prefs dialog and move it elsewhere. With "elsewhere" being the new Extensions D-Bus service, effectively turning it into a shell extensions portal. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
2020-03-04 04:05:08 +00:00
</gresource>
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
</gresources>
Reference in New Issue Copy Permalink