Closed amivaleo closed 5 years ago
Hi there. This is a duplicate of #48.
Why devs can catch duplicates while I can't? :\
Why devs can catch duplicates while I can't? :\
Well tbh I'm the only dev, so if an issue was ever filed I'll remember something about it :P Plus in this case, the title of the other issue was different enough from this one that Github didn't pick it up.
The Flatpak sandbox is starting to feel too restrictive. Aside from this issue, it also blocks having a custom "Open File" dialog (for the "Add a Document" function). If it starts blocking more stuff, I'll start considering asking Flatpak access to the whole home
dir.
Well tbh I'm the only dev
Yep, but this is not always the case. Well... It's just that I'd prefer not to bother with duplicates.
I can't be of any help about the flatpak-thing. The workflow for me is this: I find an issue > I file that in a bug report here > magic happens > a new release appears which fixes that issue. You are the one doing the magic. I can't help with the ingredients (like this flatpak permission/whatevere). 😄
I can't be of any help about the flatpak-thing. The workflow for me is this: I find an issue > I file that in a bug report here > magic happens > a new release appears which fixes that issue. You are the one doing the magic. I can't help with the ingredients (like this flatpak permission/whatevere). :smile:
Well changing the Flatpak permissions is a trivial thing to do. I'm wondering whether Slicer should do it (sacrifice the sandbox) so it can better achieve its goals.
So... Basically Slicer can't store the path in a variable and "cd" to that if it has no permission?
What happens now is that Slicer gets a file, but the path to the file is a fake one inside the sandbox. For example instead of /home/amivaleo/Documents/file.pdf
it gets /var/app/pdfslicer/docs/file.pdf
, and only that file will be present in the fake path (i.e. it isn't a mirror of the original folder).
This is great for security, but it also means I don't know where the file came from.
When saving files, Slicer also gets a fake path, but Flatpak then syncs any changes in the fake file to the actual file.
Not using the sandbox would mean that Slicer would be always working on the real paths, but also that it could read and write any file in your home
folder without the user giving explicit permission. I mean it's not like I would do that, but having the sandbox is a guarantee to the user that this can't happen.
Oh... Ok, I see people getting mad only if you dare to ask for such permission.
It's quite a pain the backside not to have the feature for which I opened this issue. Consider that I was working on several files in a quite nested folder ( ~/Documenti/Missioni/Russia/Rimborso/ ) and the Download folder.
4 levels of gerarchy among a lot of folders.
I don't have any idea for helping here. :|
Oh... Ok, I see people getting mad only if you dare to ask for such permission.
The thing is, I don't need to ask! Once a Flatpak application that has permission to access your filesystem is installed, it's game over: it can access whatever it wants (Edit: like a "normal" application installed from your distribution's repositories).
In fact, I would wager that around 95% of the apps published on Flathub have this permission. In part because they weren't designed for a sandbox, and in part because living in a sandbox is a pain in the backside, as you can see.
So the more direct question I wasn't asking is: should Slicer also ditch the sandbox?
should Slicer also ditch the sandbox?
If your life become easier, and users get some more features or Slicer works a bit more nicely... I think that you should consider to suffer a bit to get such permission.
I agree, I was just waiting for someone else's complicity :smile:
The game is on, then. Slicer will get access to the host filesystem, and this thing will get implemented
Which default folder should Slicer set in different situations? This is what I have in mind:
What do you think?
When opening a document: try to remember the path of the previous session (if it doesn't exists anymore > home folder). Jumping to the home folder is just 1 click, but reaching some long path takes a lot of time. And if that path is the same of the previous session...
When adding a document: I agree
When saving a document: it's more likely that the user remember the last path he opened instead of that of the original file. I see your rationale here, and I would agree with you... If I trusted more about the average user. 😄
All in all: same behaviour for all of the cases.
@amivaleo
- When opening a document: try to remember the path of the previous session (if it doesn't exists anymore > home folder). Jumping to the home folder is just 1 click, but reaching some long path takes a lot of time. And if that path is the same of the previous session...
Gnome strongly encourages app developers to let the environment set the default folder of an Open File dialog, and I prefer to respect that.
When adding a document: I agree
When saving a document: it's more likely that the user remember the last path he opened instead of that of the original file. I see your rationale here, and I would agree with you... If I trusted more about the average user. smile
This is some good reasoning, and I agree. :+1:
Thanks for the suggestions!
Implemented as of 0aff8d9bed174065dea418029f35d5da6d701165.
Gnome strongly encourages app developers to let the environment set the default folder of an Open File dialog, and I prefer to respect that.
I think that it's definitely acceptable if the open-file-dialog leads to the home folder the first time you click it in a fresh new session.
Please notice:
=> pdfslicer should open the path in which the original file is located.
@amivaleo
I think that it's definitely acceptable if the open-file-dialog leads to the home folder the first time you click it in a fresh new session.
Just to clarify, do you think that the "Open File" dialog should lead to an environment-default folder only the first time in a session, and later use the last open/added file's folder?
Please notice:
open nautilus and select a pdf file
open that using pdfslicer using the context-menu
try to add another pdf in the same pdfslicer session
=> pdfslicer should open the path in which the original file is located.
Right now in master, when adding another file, Slicer uses the path of the last opened/added file. Is this not what you had in mind?
I haven't been able to publish a new version with the current changes because I'm having a small problem with Flathub.
This is what I have in mind:
when adding another file, Slicer uses the path of the last opened/added file. Is this not what you had in mind?
Yes! But the thing went on on its own. ^_^
@amivaleo
If I'm understanding correctly, the change you are proposing is that the open-file-dialog should use the same directory as the add-file-dialog after a file has been opened?
If I'm understanding correctly, the change you are proposing is that the open-file-dialog should use the same directory as the add-file-dialog after a file has been opened?
Yes.
I think it is likely that the pdf the user wants to edit are probably in the same folder. I think this is a "good" guess, but what I care the most is that the add-file-dialog loads the very same folder as the previous loaded file (which could've been loaded using the open-button or the add-button, it doesn't matter). That is because it is quite likely that the user already put all the files he wants to merge in the same folder, say ~/A/B/C/D/E/F/G, so it is quite frustrating to start again from ~ (or the "recent" folder) each time.
The add-file-dialog already works this way, and I don't really care either way about the open-file-dialog, so let's go with your proposal.
Done as of 50b15fc37a076491d1606b79cb6928e229f239e5.
Hi!
I've just finished using Slicer after a tons of splits/merges. Most of my pdf were nested in the same folder or in one subfolder of the same path.
At some point I got quite stressed from the fact that the open-file-dialog forgets the last path I checked.
Can you please consider to make Slicer remember the path of the "last open pdf"?
I open a pdf in ~/1/2/3/4/5/ > I close and reopen Slicer and try to open a pdf file > the dialog shows the content of the path ~/1/2/3/4/5/
I open a pdf in ~/1/2/3/ > I try to add a pdf > the dialog shows againg the same path ~/1/2/3/
What do you think about this?