If this option is specified, the remaining arguments are scanned, and all arguments that are enclosed between a pair of ‘@@’ arguments are interpreted as file paths, exported in the document store, and passed to the command in the form of the resulting document path. Arguments between ‘@@u’ and ‘@@’ are considered uris, and any file: uris are exported. The exports are non-persistent and with read and write permissions for the application.
Could be permission issue?
Why don’t you just remove the --file-forwarding part from the Exec line of the .desktop file?
Well, I should have tried that indeed, as the command without the --file-forwarding option was working from the command line… and it also works if I remove it from the .desktop file.
So problem fixed, but then why does Fedora install the .desktop file with this --file-forwarding option in the first place? what is this %f supposed to be? which file?
That’s a placeholder for a file that is opened with the app. In the case of Recipes, it can only open files of type application/vnd.gnome.recipes.export. There are other specifiers like %F for multiple files or %u for a URI. This is all in the Desktop Entry spec.
This is a flatpak feature as described above. Its purpose is to provide access to files that are outside the sandbox by forwarding them through the document portal. For example, this would allow you to double click on a text file and have it open in an editor that has no filesystem access.
When the app is launched by itself (rather than opening a file), the %f should be automatically removed by the launcher, and flatpak won’t try to forward anything when it finds nothing between the @@s.
You’re using GNOME, right? How are you trying to launch the app? Do you see anything in the journal when you do so? (journalctl -b)
It’s the last one, but you shouldn’t edit any of those files. Any changes should be made by copying it into ~/.local/share/applications.
(You can stop reading here if you don’t care about flatpak implementation details.)
/var/lib/flatpak/app/org.gnome.Recipes/current/active/files/share/applications/org.gnome.Recipes.desktop is the raw .desktop file, the same as you’d find in a non-sandboxed version of the app.
/var/lib/flatpak/app/org.gnome.Recipes/current/active/export/share/applications/org.gnome.Recipes.desktop is that file after being ‘mangled’ by flatpak, most notably rewriting Exec to invoke flatpak run
The second file is symlinked into flatpak’s exports dir: /var/lib/flatpak/exports/share, which is in XDG_DATA_DIRS. There’s an extra indirection here because you can have multiple branches of an app installed but only the ‘current’ one is exported. This is controlled by the current symlink that I used above.
Hi Chris, thanks for the detailed explanations.
Yes, I am using Gnome on Fedora 38.
Actually, what i did is that I used alacarte to modify the desktop config of Recipes, which apparently created the file ~/.local/share/applications/org.gnome.Recipes.desktop as you recommended. After this, clicking on the Recipes icon would just work.
The funny thing is that I renamed this file (to .backup) to see if I could reproduce the problem, but even with this file out of the way, clicking the icon still works now! (I logged out of Gnome, and back in: same, it works).
I wanted to see if I could spot any error in the journal: as everything is working, unsurprisingly, there is no error about Recipes in the journal; so I grepped for previous days. I do see some funny messages, but I doubt they have anything to do with my (original) problem, as there is only a couple of them at a given time, and then nothing: