flathub / com.github.jeromerobert.pdfarranger

https://flathub.org/apps/details/com.github.jeromerobert.pdfarranger
8 stars 8 forks source link

Use portals for file access #13

Open dreua opened 3 years ago

dreua commented 3 years ago

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 commented 3 years ago

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

dreua commented 3 years ago

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

dreua commented 3 years ago

Results from first test

Works

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

UX issue

oscfdezdz commented 1 year ago

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 commented 1 year ago

Huh does this mean that https://github.com/flatpak/xdg-desktop-portal/issues/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 commented 1 year ago

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 :facepalm:

oscfdezdz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 4 months ago

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 commented 4 months ago

@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.