Use portals for file access

[dreua]

We currently request access to filesystem=host (Updated 2021-02-20). If I understand correctly, it should be possible to drop that in favor of a so called portal. PRs and info welcome! I'd also be interested in seeing another portal-using app for testing and to have a look a the source code.

[dreua]

Note: We may need to check how file writing and temporary files works without full "home" access...

[dreua]

Useful information: https://docs.flatpak.org/en/latest/portals-gtk.html
Testing in progress in #15

[dreua]

Results from first test

Works

• Open
• Save
• Export

All 3 tested with both, files from home as well as with files from a different filesystem, i.e. not home. Did not have a network fs handy but I'm quite sure that will be no issue.

Fails/Todo

• Drag and Drop between pdfarrangers
• Save is pre-filled with /run/user/1000/doc/...
• Drag and Drop from file explorer (nautilus)
• Save without explicitly adding file extension. (i.e. just foobar as filename) Probably not flatpak related, need to check logs.

UX issue

• File choosers can be hidden behind main window (did we have this problem before? I seem to vaguely remember that...)

[oscfdezdz]

I'm not sure about this, but it seems that GTK 3.24.37 has improved file access with portals. See https://gitlab.gnome.org/GNOME/gtk/-/commit/9f81db139d03a1b7d9bdac298fb6424a14d645cb

[dreua]

Huh does this mean that flatpak/xdg-desktop-portal#99 is now resolved for Gtk3? Would you like to test / create a PR so that we can finally use portals in PDF Arranger?

[dreua]

I'll probably wait until Gtk 3.24.37 hits Fedora before I consider working on this.

Edit: Disregard this, were working on Flatpaks not Fedora 🤦

[oscfdezdz]

Trying to remove filesystem=host permission without making any code changes keeps drag and drop between pdfarrangers working correctly. Save dialog prefilled with /run/user/1000/doc/... the first time although it did not happen again. Save dialog issue is still present. Drag and drop from nautilus (44) does not work. However, the error shows the complete file path, which it should not, I think, and the file extension problem is still present.

[dreua]

Thank you for testing! Drag and drop from nautilus is important imo, we should look into that first. The path on save would also be a significant reduction in usability, haven't decided whether that would be a blocker though.

[oscfdezdz]

To achieve drag and drop with Nautilus we have to manage files as Gio File, instead of using their path. I have managed to get the most basic functions like opening or importing a file to work but I have noticed that files are managed given their path in most of the cases, which will take some more time.

[dreua]

Okay, that sounds like a bigger source code change, we should take this to the main repository in order to discuss it with the other maintainers. Maybe you can create a draft PR over there so we can easily get an idea how that would work. One point come specifically to my mind: Drag and drop between PDF Arranger instances is done in a custom text format, which of course also uses file paths. This could become an issue if we absolutely need to use Gio file objects.

[t-nil]

Today I installed PDFArranger (Flathub), opened (via dialog) a PDF, made some changes and saved it. No errors, PDF was saved as expected.

Nautilus drag 'n' drop I cannot test sadly, since I use Xfce.

[dreua]

@t-nil Yep, it has full filesystem access by default and therefore doesn't need portals. This becomes complicated if you want to improve the sandboxing and take the full filesystem access away. I think open and save with the dialog already works but drag and drop didn't the last time I checked. And I consider drag and drop a crucial feature of PDF Arranger which should work out of the box by default, at least in environments which support it.