summaryrefslogtreecommitdiff
path: root/src/ephy-main.c
diff options
context:
space:
mode:
authorPhaedrus Leeds <mwleeds@protonmail.com>2021-11-29 17:53:02 -0800
committerPhaedrus Leeds <mwleeds@protonmail.com>2022-03-21 13:07:44 -0700
commit7547094e246e1e9277a6fbc66f1a7fd6db7b5b6e (patch)
tree55325b5c8358e03120f91c30c4a702f476c15ef8 /src/ephy-main.c
parent9d6193b25dd0a39ac604b0bec1877b1e5d5b4fa3 (diff)
downloadepiphany-7547094e246e1e9277a6fbc66f1a7fd6db7b5b6e.tar.gz
Add a WebAppProvider D-Bus interface
This commit adds a D-Bus service that exposes the web apps managed by Epiphany so that a client can enumerate them, install a new one, or remove an installed one. The intended client is GNOME Software, since I am soon going to add back a webapp plugin to Software which will make use of this interface. This is part of a larger effort to improve the support for Progressive Web Apps in GNOME (though Epiphany's web apps do not support PWA manifest features). The great thing about having this be a service exposed by Epiphany, rather than having Software try to install Epiphany-compatible web apps on its own as it used to do, is that the implementation of how to create and manage the web apps can stay in Epiphany, and there can never be disagreement between Epiphany and Software about the proper on-disk format for them (e.g. the algorithm used for generating the app ID from the name). The goal for the PWA project is to support Flatpak'd Epiphany, whereas currently only non-Flatpak Epiphany can do web apps. This will be accomplished with new portals to allow installing and removing the .desktop launchers. The Flatpak support requirement is reflected in the design of the API here, specifically the install_token parameter for the Install() method. This token is to be acquired by the client of the D-Bus interface (Software) so that the installation can be achieved without any additional user interaction since the user would've already clicked "Install" in Software. Web app installation directly via Flatpak'd Epiphany's UI would involve a dialog created by the portal; this is because we don't want sandboxed applications in general to be able to create desktop launchers without user interaction. The Uninstall() method by contrast doesn't require such a token, because the portal can ensure that only apps created by an application are deleted by that application. The GetInstalledApps() method is implemented by looking at the profile directories of the apps, because we don't want to have to poke a sandbox hole to allow access to the actual desktop files.
Diffstat (limited to 'src/ephy-main.c')
-rw-r--r--src/ephy-main.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/ephy-main.c b/src/ephy-main.c
index 48b6c684b..bcf5ce703 100644
--- a/src/ephy-main.c
+++ b/src/ephy-main.c
@@ -370,7 +370,7 @@ main (int argc,
/* Delete the requested web application, if any. Must happen after
* ephy_file_helpers_init (). */
if (application_to_delete) {
- ephy_web_application_delete (application_to_delete);
+ ephy_web_application_delete (application_to_delete, NULL);
exit (0);
}