search

junrrein / pdfslicer

A simple application to extract, merge, rotate and reorder pages of PDF documents
https://junrrein.github.io/pdfslicer/
GNU General Public License v3.0
149 stars 18 forks source link

Remember the path of the last open/added pdf #108

Closed amivaleo closed 5 years ago

amivaleo commented 5 years ago

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"?

What do you think about this?

junrrein commented 5 years ago

Hi there. This is a duplicate of #48.

amivaleo commented 5 years ago

Why devs can catch duplicates while I can't? :\

junrrein commented 5 years ago

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.

amivaleo commented 5 years ago

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). 😄

junrrein commented 5 years ago

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.

amivaleo commented 5 years ago

So... Basically Slicer can't store the path in a variable and "cd" to that if it has no permission?

junrrein commented 5 years ago

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.

amivaleo commented 5 years ago

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

junrrein commented 5 years ago

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?

amivaleo commented 5 years ago

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.

junrrein commented 5 years ago

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

junrrein commented 5 years ago

Which default folder should Slicer set in different situations? This is what I have in mind:

What do you think?

amivaleo commented 5 years ago

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

  2. When adding a document: I agree

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

junrrein commented 5 years ago

@amivaleo

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

  1. When adding a document: I agree

  2. 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!

junrrein commented 5 years ago

Implemented as of 0aff8d9bed174065dea418029f35d5da6d701165.

amivaleo commented 5 years ago

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:

  1. open nautilus and select a pdf file
  2. open that using pdfslicer using the context-menu
  3. try to add another pdf in the same pdfslicer session

=> pdfslicer should open the path in which the original file is located.

junrrein commented 5 years ago

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

  1. open nautilus and select a pdf file

  2. open that using pdfslicer using the context-menu

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

amivaleo commented 5 years ago

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. ^_^

junrrein commented 5 years ago

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

amivaleo commented 5 years ago

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.

junrrein commented 5 years ago

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.

junrrein commented 5 years ago

Done as of 50b15fc37a076491d1606b79cb6928e229f239e5.