Commit Graph

4 Commits

Author SHA1 Message Date
Florian Müllner
8c1cf3fa3d dbusServices/extensions: Instruct gjs to generate unique GType names
Like the main gnome-shell process, the extensions service loads code from
extensions. It therefore makes sense to prevent GType name clashes there
as well, just like we already to in the gnome-shell process.

This may break some extensions that use the old type name in .ui files,
but they can be fixed easily by specifying an explicit GTypeName.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2024>
2022-01-05 19:28:25 +00:00
Florian Müllner
edd34c50d9 Port extensions app and portal to GTK4
With the previous preparations in place, it is time to take the plunge.

As both the app and the portal use the same small library for handling
external windows, port everything at once to avoid the hassle of building
and installing two versions of the library.

With the portal using GTK4 now, all extensions must port their preference
widgets as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1495>
2021-01-14 13:03:21 +00: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