Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support the filepicker portal #20

Open
secretmango opened this issue May 23, 2024 · 3 comments
Open

support the filepicker portal #20

secretmango opened this issue May 23, 2024 · 3 comments

Comments

@secretmango
Copy link

hey, very smooth app!

For the Flatpak to work well, and on Linux in general it looks nicer, it would be a huge benefit to support the native xdg-desktop portal.

This means the Flatpak would not need any static filesystem permissions.

@scrivanolabs
Copy link
Owner

scrivanolabs commented May 23, 2024

Hi there, thanks for the feedback.
Unfortunately, I don't think Scrivano can rely on file choosers via Flatpak. The reason is that autosaving files (which is a core feature of Scrivano) requires reading/writing files without user interaction.

@secretmango
Copy link
Author

secretmango commented May 23, 2024

Hi, interesting reasoning.

I see how the flatpak permissions are pretty annoying, but autosaving should not be the problem.

When opening a file via the portal it is symlinked to the apps container, so autosaving works. A "user interaction" really only is when users would open the portal program. An interaction within the Flatpak is not a "user interaction", as the portal is the one with "the power".

The only workflow that breaks because of this opening previously opened documents from within the app. So a workflow

  1. open filemanager
  2. open document, opens scrivano
  3. scrivano gets access to the file and can save as much as it wants.

works fine.

Example: KDE Okular Flatpak works completely without filesystem access. Both opening from the filemanager and via the portal give it the ability to save changes with "Ctrl + S" i.e. without opening a portal i.e. without "user interaction".

Only if you do something like KeepassXC, displaying and opening the previously edited document(s) when launching the app, then it is problematic.

I think this could be circumvented by using "xdg-open" but I am not sure.

@scrivanolabs
Copy link
Owner

When opening a file via the portal it is symlinked to the apps container, so autosaving works.

Hmm interesting, I didn't know about this so I'll look into this.

The only workflow that breaks because of this opening previously opened documents from within the app.

Yes, this is another use case I'm not sure could be supported with Flatpak (Scrivano does allow you to this), but I'll investigate.

However, more importantly, in a future update I plan to add an in-app side bar (something I'm already working on) which would allow the user to navigate their existing documents (essentially providing a view of a given folder on their system). This I believe would require file system permissions and I would not want to avoid bifurcating the experience for Flatpak and non-Flatpak users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants