Sending Temporary Desktop Entries over D-Bus: New Portal?

[ryanabx]

The Desktop Entry Spec contains tons of metadata about an application, including icons, MIME types, and additional actions an app can use. Pretty much all the desktop environments I have used in the past have had support for the spec.

There are some apps which are portable that aren't able to register icons and MIME types and the like, the former of which has been discussed in wayland protocols.

In the linked MR, which is Matthias Klumpp's proposal for solving the problem of apps with no permanent installation wanting to set icons, this comment by Simon Ser and the related discussion interested me.

What kind of solution do you imagine you'd prefer?

"Some way to dynamically register a .desktop file maybe? But I'm not even sure this should be part of Wayland TBH, since desktop entries cover more than just the compositor. For instance one may want to correctly handle MIME type associations or URI associations while the app is opened: for instance if the user opens an IRC client in an AppImage, irc:// URLs should be handled there…"

Since desktop entries are less compositor related, I thought about the functionality maybe being a desktop portal. There's probably lots of things I'm not considering, but I think a D-Bus api for an app to send a desktop entry to any necessary party would be nice.

cc @emersion

[ryanabx]

This idea didn't gain any traction, but since I'm thinking about it tonight, I'll list the two use cases I've had in the last few hours.

Presenting a temporary icon over d-bus.

Consider these two programs without named icons I have on my app list (running COSMIC DE):

One of these is Visual Studio Code (running inside a toolbox, so .desktop entries are registered inside the toolbox, not out)
The other is RStudio, which has the same issue

I can't differentiate these applications, and I find myself getting frustrated at clicking the wrong one at times.

Registering file type associations over d-bus

RStudio normally registers itself to run on all .R files. Because I'm on a Fedora Atomic desktop, I run RStudio on a toolbox. While I have RStudio open, I'd like to be able to double click an .R file with my file manager of choice to automatically open it in RStudio.

I hope this portal idea can be considered more, especially because a compositor-based icon solution is being heavily debated on in wayland-protocols. xdg-toplevel-icon would only solve part of one problem and many other problems I don't have much feeling towards solving, and some people outright don't want allowed (such as dynamic/animated icons and multiple icons per application)

[swick]

I think the idea to transiently register an app is a good one. Portals are however targeted at (confined) applications so I think it makes more sense to have a dbus service which is not a portal.

[ssokolow]

I'll probably initially disallow exec entries even though I have ideas for cool applications of them.

I was imagining something like:

1. User launches a transient application
2. The application calls the D-Bus API (possibly provided via a toolkit abstraction or a shell script wrapper that calls dbus-send... so it'd be a good idea to verify that the type signature is something dbus-send can emit.)
3. If the .desktop file contains an Exec, a dialog pops up saying something like "Application X would like to..." and a list of things like "Add itself to the launcher as 'Name'" and "Register itself as an option for opening [number] file types [expander for list of types]"
4. The user clicks one of a set of Never/Not Now/Allow buttons.

[ssokolow]

Does flatpak let you set a permission for an app to use a specific d-bus api? If so, the standard for the d-bus api can remain the same (namespace and such) and flatpaks can request usage of the specific d-bus interface.

Yes. Flatpak provides a D-Bus proxy and it's integral to its security model. The relevant arguments (either in a flatpak-builder manifest's finish-args list, fed to flatpak override for permanent changes (or graphically set using Flatseal or the relevant KCM in new enough KDE versions), or fed to flatpak run for one-time changes) are:

• --own-name=X (session bus, receive messages at X)
• --talk-name=X (session bus, send messages to X)
• --system-own-name=X (system bus, receive messages at X)
• --system-talk-name=X (system bus, send messages to X)

Portals are special-cased with a hard-wired "allow this" no matter what the manifest permissions say because, in the long term, the goal is for as many manifest permissions as possible to only be needed for compatibility with legacy apps.

[ryanabx]

Good news, I've got a working implementation of a DBus daemon that temporarily registers desktop entries:

https://github.com/ryanabx/desktop-entry-daemon/tree/master

I also have the first usage example in the form of a program that registers toolbox desktop entries on the host (ideally this could support podman and docker too but that's still pending):

https://github.com/ryanabx/container-desktop-entries

I'm also building these as packages in a COPR for testing if anybody uses fedora:

https://copr.fedorainfracloud.org/coprs/ryanabx/ryanabx-tools/packages/

I have some thoughts that I gathered from implementing this, so I'll make another comment with those.

[ryanabx]

• My first thought after hashing out the dbus implementation was how difficult it was to 'enforce' a temporary desktop entry. Is it possible to follow a process and get notified when the process exits so the entry can be cleared then? Currently the implementation only clears when logging out / powering off and when the daemon restarts, but I'd like it to be able to delete entries once the process its associated with exits.

• The current implementation asks for a file path to the .desktop entry, rather than asking for the .desktop entry string as a parameter. This is because I wanted both the icon and the .desktop entry requests to ask for similar things, so both ask for the full path to the resource to register. I wanna know what people think about that, if there's a better way to do it, I want to know.

• The daemon is a user service, because I figured that's less easy to abuse, and we really don't need to register system-level desktop entries anyways.

If I think of more things, I'll put them here

[ssokolow]

The current implementation asks for a file path to the .desktop entry, rather than asking for the .desktop entry string as a parameter. This is because I wanted both the icon and the .desktop entry requests to ask for similar things, so both ask for the full path to the resource to register. I wanna know what people think about that, if there's a better way to do it, I want to know.

That won't work if the application is inside some kind of virtualized environment (eg. a container) that results in it having a different view of the filesystem.

(eg. You can't use the MakeHuman integration plugin with Flatpak'd Blender because MakeHuman passes paths to /usr/share/makehuman... for things like textures.)

That's also why drag-and-drop from or into Flatpak'd apps often doesn't work. They can't see the path the sending application provided. (eg. You can't drag-and-drop pages out of Flatpak'd MComix because MComix's /tmp isn't visible to the rest of the system.)

In this day and age, it's just generally a bad idea to assume that two applications have the same view of the filesystem.

[ryanabx]

That won't work if the application is inside some kind of virtualized environment (eg. a container) that results in it having a different view of the filesystem.

(eg. You can't use the MakeHuman integration plugin with Flatpak'd Blender because MakeHuman passes paths to /usr/share/makehuman... for things like textures.)

That's also why drag-and-drop from or into Flatpak'd apps often doesn't work. They can't see the path the sending application provided. (eg. You can't drag-and-drop pages out of Flatpak'd MComix because MComix's /tmp isn't visible to the rest of the system.)

In this day and age, it's just generally a bad idea to assume that two applications have the same view of the filesystem.

Yeah, I regret to have anything that references file paths, but how do I register icons for example without doing some kind of file path? That'd be way too heavy for DBus :/

Open to any and all ideas to get around that hurdle

Edit: Just realized I made a new comment, so @ssokolow for visibility

[swick]

If the app provides a number that doesn't correspond to a PID in its own pidns, the function returns FALSE. The pidns is queried by x-d-p in xdp_app_info_ensure_pidns without any cooperation required from the client.

[ryanabx]

Sorry I keep asking, I just don't know PID namespaces very well and the internet isn't much help -- do we know the namespace the client app is in when it sends us its PID? If not, we'd have to do some guesswork to find out its namespace, no?

I see you saying if the app provides a number that doesn't correspond to a PID in its own pidns, but if we don't know the apps pidns, how can we figure that out?

[swick]

do we know the namespace the client app is in when it sends us its PID?

This is a non-trivial question. x-d-p has a bit of convoluted code to get the pidns in a secure fashion that I would not recommend trying to re-invent. Maybe this really should be a portal, then you get this kind of stuff for free.

[ryanabx]

Maybe. Alternatively, I am able to get the sender's process ID from the dbus message. For now, I'm just using that to define the lifetime of the desktop entries. When the sender process exits, the desktop entries go away.

There's also the question of if we want a method to register entries with a session lifetime (i.e. they last after the client's lifetime but not after log out/log in. I think it would be okay to allow that on a separate method, perhaps it could be separated with different permissions.

[ryanabx]

I should note that I'm still not opposed to making it a portal -- I think that it'd have wider adoption if it were a portal.
Unfortunately, my forte is rust and I don't want to work with a C codebase to implement the portal if it were accepted though :/