Add dynamic launcher portal

[mwleeds]

This is not ready to be merged since I haven't implemented the gnome backend or the libportal side of it, and I haven't tested it. But it can be reviewed.

For context see #681 and #326

[mwleeds]

Do we really still care about Ubuntu 16.04 support? It is EOL except for their ESM program.

[mwleeds]

Do we really still care about Ubuntu 16.04 support? It is EOL except for their ESM program.

I made the new portal only compile when we have GLib 2.66, so we can still maintain compatibility for the existing code with old GLib for the sake of security patches.

[mwleeds]

I realized that the implementation currently doesn't allow the editable-icon option to be implemented by the backend, even though the option is there. I'm going to work on getting this tested without editable icons for now; that may need to be a v2 feature.

[mwleeds]

I also notice that the notification portal takes an icon as a GVariant (made with g_icon_serialize()) whereas here we take it as a file descriptor. I made it an fd because I thought it's not best practice to send an image in a D-Bus message due to message size limits and performance concerns. I still think this is a good design, but just noting that it's not in line with some existing code we have.

[ramcq]

I also notice that the notification portal takes an icon as a GVariant (made with g_icon_serialize()) whereas here we take it as a file descriptor. I made it an fd because I thought it's not best practice to send an image in a D-Bus message due to message size limits and performance concerns. I still think this is a good design, but just noting that it's not in line with some existing code we have.

I'm not sure it's worth it...? My recollection is that a D-Bus message can be 10MB in size, and the icons are expected to be significantly smaller. Requiring a fd means that if you are composing / sizing / etc the icon dynamically you are forced to place it on disk or set up a memory-backed fd (/dev/shm I guess?) which is a bit of a pain. @matthiasclasen may have an opinion on this but for a relatively rare process of adding an app, requiring an fd might be overkill. If we were streaming video, sure... :)

[mwleeds]

I also notice that the notification portal takes an icon as a GVariant (made with g_icon_serialize()) whereas here we take it as a file descriptor. I made it an fd because I thought it's not best practice to send an image in a D-Bus message due to message size limits and performance concerns. I still think this is a good design, but just noting that it's not in line with some existing code we have.

I'm not sure it's worth it...? My recollection is that a D-Bus message can be 10MB in size, and the icons are expected to be significantly smaller. Requiring a fd means that if you are composing / sizing / etc the icon dynamically you are forced to place it on disk or set up a memory-backed fd (/dev/shm I guess?) which is a bit of a pain. @matthiasclasen may have an opinion on this but for a relatively rare process of adding an app, requiring an fd might be overkill. If we were streaming video, sure... :)

Yeah the way it's currently implemented:

• Software doesn't have to do any extra work since it already caches remote icons to disk so we just pass that path to libportal which gets an fd for it (but maybe Software could start modifying the icons like Epiphany does).
• Epiphany downloads icons to disk (except on the fallback path that uses favicons), then reads it, makes it have rounded edges and be a certain size, and then writes it back out to a tmp file to be passed to libportal.

So if message size limits aren't an issue it might make sense to pass a GVariant.

[mwleeds]

Separately, there is the question of how to handle installation of a launcher that would overwrite an existing one. Currently the portal just does the overwrite without confirmation, but Epiphany checks if the app already exists before calling the install method and presents a confirmation dialog if so. It could make sense to have some sort of overwrite confirmation in the portal implementation, but having it controlled by the application has the advantage that it can clear any other state associated with the launcher being overwritten. However it does mean that the confirmation dialog is separate rather than a child of the main portal dialog.

[mwleeds]

So if message size limits aren't an issue it might make sense to pass a GVariant.

I checked 18 PWAs and found one icon that was 275 kB but all the rest were an order of magnitude smaller.

[matthiasclasen]

Message size would be an issue for photos. I don't see it being a problem for icons

[mwleeds]

Message size would be an issue for photos. I don't see it being a problem for icons

Okay, I can change the implementation to use a GVariant instead for the icon.

In other news, I just was able to successfully test this with unsandboxed Epiphany. Still need to test sandboxed Epiphany but it seems to be working so far.

[GeorgesStavracas]

One common pattern in portals that can provide a variety of options is to expose the availability of these options using D-Bus properties. In this case, I think it needs a SupportedLauncherTypes property (uint32):

SupportedLauncherTypes:

A bitmask of available launcher types. Currently defined types are:

<simplelist>
  <member>1: Application. A launcher that represents an application.</member>
  <member>2: Link. A launcher that represents a webapp.</member>
</simplelist>

PrepareInstall() would then receive a launcher_type (uint32) as part of the options vardict. Knowing ahead of type what kind of launcher it is will allow portal implementations to provider more specialized interfaces. Despite being technically a bitmask, PrepareInstall() must only accept one type. ¹

By providing a launcher_type, the naming of the url option doesn't feel natural to me - perhaps rename to target? Ideas welcomed.

---

¹ - This can be validated with __builtin_popcount(launcher_types) == 1.

[mwleeds]

One common pattern in portals that can provide a variety of options is to expose the availability of these options using D-Bus properties. In this case, I think it needs a SupportedLauncherTypes property (uint32):

SupportedLauncherTypes:

A bitmask of available launcher types. Currently defined types are:

<simplelist>
  <member>1: Application. A launcher that represents an application.</member>
  <member>2: Link. A launcher that represents a webapp.</member>
</simplelist>

PrepareInstall() would then receive a launcher_type (uint32) as part of the options vardict. Knowing ahead of type what kind of launcher it is will allow portal implementations to provider more specialized interfaces. Despite being technically a bitmask, PrepareInstall() must only accept one type. ¹

By providing a launcher_type, the naming of the url option doesn't feel natural to me - perhaps rename to target? Ideas welcomed.

¹ - This can be validated with __builtin_popcount(launcher_types) == 1.

That makes sense to make the launcher types more explicit. But I guess application launchers wouldn't have a target so it would be NULL in that case. Still seems fine to name it target in case there's another use for it in the future. The implementation currently only uses it to display the URL in small text at the bottom of the dialog.

[mwleeds]

Currently we only add a TryExec= entry to the desktop file for Flatpaks, since we know how to find the wrapper script for them in e.g. ~/.local/share/flatpak/exports/bin/. We then use that in migrate_renamed_app_launchers() which gets run at startup to rename launchers for apps that have been renamed and delete launchers for apps that have been uninstalled. Presumably we want the latter part, deleting no-longer-needed launchers, to work for non-Flatpaks as well, so we could:

• Try to determine the absolute path to use as TryExec= by looking at /proc/$(pid of caller)/exe, but this isn't perfect. It doesn't work for something executed in a toolbox container for example, or
• Use the first string in the Exec= line, since TryExec= doesn't have to be an absolute path according to the spec, or
• Require the caller add a TryExec= line.

For Epiphany I couldn't find an easy way to get the absolute path to the binary so I had it add TryExec=epiphany (link to MR).

[mwleeds]

Message size would be an issue for photos. I don't see it being a problem for icons

Okay, I can change the implementation to use a GVariant instead for the icon.

Looks like there's no easy way to tell the file format of a serialized #GBytesIcon, so we could either (a) gain a dependency on gdk and use gdk-pixbuf to write it out as a png regardless of what it originally was, or (b) add a parameter so the caller can specify the file extension, with the allowed values the same as Flatpak (".png", ".jpeg", ".svg"). The second option seems simpler so I'll go with that.

[GeorgesStavracas]

Looks good. We shall land this now. Thanks!

[GeorgesStavracas]

@mwleeds let's focus on the -gnome and -gtk portal implementations now. I've filed https://bugs.kde.org/show_bug.cgi?id=451510 for KDE.

[mwleeds]

@mwleeds let's focus on the -gnome and -gtk portal implementations now. I've filed https://bugs.kde.org/show_bug.cgi?id=451510 for KDE.

Sounds good thanks for filing that. Of course there are other back-ends as well but I don't think we have an obliglation to file a ticket for each one.

[bilelmoussaoui]

Is it possible to add the docs for the new portal?

[mwleeds]

Is it possible to add the docs for the new portal?

Yup, thanks for the reminder: flatpak/flatpak-docs#325