pdfarranger forgets file name to save when closing window

[lonnic]

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. open a file pdf
2. erase one or more pages
3. close pdfarranger
4. See error: pdfarranger forgets the name of the file ad uses xdg-desktop-portal-kde when the default file manager is thunar. Even if I use CTRL+S to save the file pdfarranger needs to insert again the same file name.

Expected behavior

the previous version was ok

[jeromerobert]

Please provide OS, GTK and PDF Arranger versions.

[lonnic]

slackware, kernel 5.15.19
GTK version: 1.2.10 (into slackware)
pdfarranger 1.9.1 FLATPAK VERSION ...
in about: I read:
It uses libqpdf 11.1.1, pikepdf 6.2.0, GTK 3.24.34 and Python 3.9.9.

[jeromerobert]

It could be related to #704 but I'm currently not able to reproduce it.

By the way, why are you talking about xdg-desktop-portal-kde and thunar ? How is that related to PDF Arranger ?

Could you provide screenshots of your save dialog ?

[lonnic]

[lonnic]

If iI close pdf arranger, it asks again the name of the original file ...
same situation if i use CTRL+S

[jeromerobert]

Ok so this because #704 and because Gtk.FileChooserNative.set_filename does not work with KDE. This must be fixed in GTK or KDE but this is beyond what I can do. We have 2 reasonable possibilities:

• Revert Use FileChooserNative insted of FileChooserDialog #704
• Add a configuration key in the .config/pdfarranger/config.ini file to let the user switch back to the GTK file chooser

@oscfdezdz @dreua any opinion ?

[kbengs]

In Windows FileChooserNative works much faster so imo we should not remove it from Windows at least.

[dreua]

Is this affecting all KDE or do we only know of this case with slackware?

[kbengs]

I see this issue on Kubuntu 22.04 with the flatpak version. Pdfarranger installed with pip works fine.

[dreua]

Thanks for checking, so that's probably a Flatpak issue that should be fixed by someone. Not sure if we should add a workaround in PDF Arranger for such stuff but we could check whether we are flatpak or not. I could probably also add a patch to the Flatpak build.

[dreua]

I updated the Flatpak to Gnome 43, could you check whether that changes anything? If no, it would be nice if someone could report that as Flatpak bug. I'll try to patch our flatpak back to FileChooserDialog once that is done.

[kbengs]

I am not sure where to find the flatpak? The version on flathub is updated 24 september. I tried to reinstall it but it did not change anything.

[lonnic]

at the moment I switched back to flatpak pdfarranger previous working version 1.8.2

flatpak update --commit=baa9335d72777702b0484932a23ac1278f2f589387b46108181c21878efae74e com.github.jeromerobert.pdfarranger

meanwhile I will update this thread when latest flatpak update will work correcty...

[siodor]

I can confirm that the same behaviour happens when I open a PDF, drag another one in to add it to the original document and then pdfarranger also forgets the path.

I'm using:

• Gentoo 2.9, up-to-date as of 27.11.2022
• KDE Plasma Version 5.25.5
• KDE Frameworks Version 5.99.0
• Qt Version 5.15.5
• Graphic Platform X11

These are the dependencies it was built with:

host /home/user # equery depgraph pdfarranger
 * Searching for pdfarranger ...

 * dependency graph for app-text/pdfarranger-1.9.1-r1
 `--  app-text/pdfarranger-1.9.1-r1  ~amd64 
   `--  app-text/poppler-22.11.0  (app-text/poppler) amd64  [introspection cairo]
   `--  dev-python/pikepdf-6.2.1  (>=dev-python/pikepdf-6.0.0) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)?]
   `--  dev-python/pycairo-1.21.0-r1  (dev-python/pycairo) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)?]
   `--  dev-python/pygobject-3.42.2  (dev-python/pygobject) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)? cairo]
   `--  dev-python/python-dateutil-2.8.2-r1  (dev-python/python-dateutil) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)?]
   `--  x11-libs/gtk+-3.24.34-r1  (x11-libs/gtk+) amd64  [introspection]
   `--  x11-libs/pango-1.50.11  (x11-libs/pango) amd64  [introspection]
   `--  dev-python/python-distutils-extra-2.47  (dev-python/python-distutils-extra) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)?]
   `--  dev-util/intltool-0.51.0-r3  (dev-util/intltool) amd64 
   `--  dev-lang/python-3.8.15_p3  (>=dev-lang/python-3.8.13) amd64 
   `--  dev-lang/python-3.9.15_p3  (>=dev-lang/python-3.9.12) amd64 
   `--  dev-lang/python-3.10.8_p3  (>=dev-lang/python-3.10.4) amd64 
   `--  dev-lang/python-3.11.0_p2  (>=dev-lang/python-3.11.0_beta4) amd64 
   `--  dev-python/setuptools-65.5.1  (>=dev-python/setuptools-65.3.0) amd64  [python_targets_python3_8(-)? python_targets_python3_9(-)? python_targets_python3_10(-)? python_targets_python3_11(-)?]
[ app-text/pdfarranger-1.9.1-r1 stats: packages (15), max depth (1) ]
host /home/user #

But I don't think that I'm using the native KDE save dialogue

This is the save dialogue when I "Save AS" from Okular:

While this is what I presume is the GTK save dialogue when I do a "Save AS" in pdfarranger:

Both show the same path.

[kbengs]

@siodor Could you confirm that this happens only if the two pdf:s are in different folders?

[siodor]

@kbengs hmm, interesting, I just noticed that pdfarranger doesn't forget the path, but instead takes the path of the drag & dropped PDF.

What I did:

1. Open /home/user/source.pdf in pdfarranger
2. Pulled in /home/scantoftp/scanned.pdf from KDE Dolphin file browser
3. Checked path when doing "Save As" and it took the path of /home/scantoftp/

Is this the intended behaviour? Could it be changed to remember the path of the source PDF because in my mind someone would want to just add additional page to a source document and save it again as it was.

[dreua]

Could someone please report this against the Flatpak Runtime (Gnome 43)? I'm not using KDE and don't like reporting bugs that I haven't seen with my own eyes.

I'll try to Revert-Patch #704 in the Flapak Build as a reward, once it is properly reported ;)

[kbengs]

Could` it be changed to remember the path of the source PDF because in my mind someone would want to just add additional page to a source document and save it again as it was.

The open PR would change it so that "save as" always goes to "first imported file" or, if it has been saved, to the last saved file.

@dreua the problem seems to be fixed by 4cb5459 I am not sure it is a bug.