Commit Graph

5 Commits

Author SHA1 Message Date
Florian Müllner
ae92c1c4eb 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>
2022-02-08 19:11:19 +00:00
Florian Müllner
073dbc3a04 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>
2022-02-08 19:11:19 +00:00
Florian Müllner
23e5cd4e10 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 10:38:24 +01:00
Florian Müllner
34e85342d8 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-23 15:39:12 +00:00
Florian Müllner
91b7474d5a 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-23 15:39:12 +00:00