The Fedora forum isn’t a bug tracker. However, talking about bugs here makes sense sometimes, to raise awareness or check if there’s an issue for others. But, when talking about it here, be sure to open issues in upstream bug trackers.
Is this Evolution from Flathub or Fedora?
You might want to report a bug at https://github.com/flathub/org.gnome.Evolution/issues if it’s from Flathub.
If it’s from Fedora, check https://bugzilla.redhat.com/buglist.cgi?quicksearch=evolution and file a bug at Bugzilla (or subscribe to an existing bug).
However, I think this is actually happening because that file does not exist… inside the flatpak, and Evolution is mainly sandboxed off from your computer’s files.
Here’s what Flatseal (an app on Flathub that lets you look at an manipulate permissions for applications that are in flatpaks) shows for me for Evolution here:
Note that there’s no access to files on your host or any in Downloads. To add the Downloads folder, you can add “xdg-download”. Or you can also run a command like this: flatpak override org.gnome.Evolution --filesystem=xdg-download:ro (which will add your Downloads folder as a read-only location that Evolution can access). I think either method would require you restarting Evolution for it to gain access.
According to https://docs.flatpak.org/en/latest/flatpak-command-reference.html, under " --filesystem=FS", you have a bunch of options:
home, host, xdg-desktop, xdg-documents, xdg-download, xdg-music, xdg-pictures, xdg-public-share, xdg-templates, xdg-videos, xdg-run, xdg-config, xdg-cache, xdg-data, an absolute path, or a homedir-relative path like ~/dir or paths relative to the xdg dirs, like xdg-download/subdir. The optional :ro suffix indicates that the location will be read-only. The optional :create suffix indicates that the location will be read-write and created if it doesn’t exist. This option can be used multiple times.
Of course, that weakens the sandbox a bit (some of the paths more than others). But keep in mind “normal” non-Flatpak’d apps would have the ability to access pretty much any file on your system. Still, I’d suggest choosing specific directories for your override.
Everything above said, I firmly believe that any file that can be dragged and dropped should be a transparent portal to send that file to the Flatpak, similar to how file selector dialogs (for open and save) work. This would be great in most cases, as you’re usually embedding the file. (However, in Inkscape, and possibly other programs, you might be linking in a file from the filesystem, so it wouldn’t always work perfectly.)
Here’s the issue about the portal for drag-and-drop and copy-and-paste (which has been closed as it has been implemented as a portal, and even in GTK4):
So, it has been added as org.freedesktop.portal.FileTransfer… but sending and receiving apps either need to add support for it or upgrade to GTK4 (which isn’t out yet), unless GTK3 adds support for it natively too.
So we’re getting there. It’s currently not ideal. But you do have workarounds for the time being.
