Hi,
I found an interesting behavior of Paperwork. Maybe it’s some distorted settings on my machine, but it only happens in Paperwork.
When I chose to open the document in the containing folder, Paperwork starts Kid3 for me. But I don’t intend to add mp3-tags to my files, I would just like to find them.
My system is a vanilla arch installation, with Xfce Desktop Environment, always kept up to date.
I installed Paperwork from the repositories.
The system default to explore directories is thunar.
I didn’t find any config file in which to change this behavior.
Kid3 is started when I click on the option “Open Folder” as your screenshot shows it.
I would expect my file browser to handle this, but no instance of the file browser starts in that moment.
I installed paperwork from the regular arch-repositories. It is not an aur package.
pacman -Ss paperwork
extra/paperwork 2.2.1-2 [Installiert]
Personal document manager for GNOME to manage scanned documents and PDFs
Is there any more information I can provide to help you hunt that issue?
Paperwork includes many methods to open a file or a directory with an application (each represented by a plugin). Can you try disabling those plugins one by one and see what works for you or not please ?
# due to a bug, you may have to run the commands
# `paperwork-gtk plugins remove (..)` twice :/
# Remove the GIO method --> it will fall back on the Dbus method
paperwork-gtk plugins remove openpaperwork_gtk.external_apps.gio
paperwork-gtk plugins remove openpaperwork_gtk.external_apps.gio
# give it a try
paperwork-gtk
# Remove the Dbus method --> it will fall back on the xdg-open method
paperwork-gtk plugins remove openpaperwork_core.external_apps.dbus
paperwork-gtk plugins remove openpaperwork_core.external_apps.dbus
# give it a try too
paperwork-gtk
# reset the plugin list --> back to the GIO method
paperwork-gtk plugins reset
The last method simply uses the command xdg-open. You can try it yourself in a terminal: xdg-open some_directory/. If this last method starts Kid3 too, it means that on your system you have somehow associated the mime-type inode/directory to Kid3.
With xdg-open ~/Downloads, thunar openes the folder Downloads.
After I removed the GIO method and started paperwork-gkt from the cli, it crashed on me as I clicked on one file that I had already scanned (you got a crash report for this event) - but it didn’t crash on the other files, so it seems to be a problem of that one file. (This information as an additional insight into the crash report…)
When I clicked on “Open Folder” from the context menue of any of the files, it opened thunar (the regular file explorer on my system) for me.
So all is fine without the GIO method. Should I proceed with removing the Dbus method also?
What features do I lack if I leave the GIO method disabled?
After I removed the GIO method and started paperwork-gkt from the cli, it crashed on me as I clicked on one file that I had already scanned (you got a crash report for this event)
The crash seems unrelated to our test. It looks like one of the image file in your document 20231113_2215_36 has been truncated to less than 4 bytes …
The exact error is:
File "/usr/lib/python3.11/site-packages/PIL/_binary.py", line 85, in i32be
return unpack_from(">I", c, o)[0]
^^^^^^^^^^^^^^^^^^^^^^^
struct.error: unpack_from requires a buffer of at least 4 bytes for unpacking 4 bytes at offset 0 (actual buffer size is 0)
(PIL is the library used by Paperwork to load the images)
So all is fine without the GIO method. Should I proceed with removing the Dbus method also?
You can try if you want, but I doubt it would bring any extra valuable information. And it’s kind of weird: I was running under the assumption that both methods do eventually the same thing. I’ll have to dig deeper to learn the actual differences between both.
What features do I lack if I leave the GIO method disabled?
Actually none. The GIO method was implemented because it was more convenient when running in a Flatpak container.
Just so you know, some Paperwork updates may reset your plugin list.
