SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** When hitting CTRL+D or clicking 'View Document' in the context menu, a local PDF file that has been made available after the search results list has been built is not seen as existing. STEPS TO REPRODUCE 1. Open a KBibTeX file with local PDF documents attached in entries. 2. Delete/Unlink/make-it-a-broken-link linked local PDF file 3. Hit CTRL+D / View Document on an entry with that linked PDF 4. (PDF is not opened, makes sense) 5. Make PDF available again 6. Hit CTRL+D / View Document on an entry with that linked PDF again OBSERVED RESULT PDF is not opened, instead other source like link is opened again EXPECTED RESULT PDF is opened SOFTWARE/OS VERSIONS Manjaro Linux ADDITIONAL INFORMATION I guess the list including the available viewable sources is built at the beginning. I suggest checking for existence of the sources right at the time CTRL+D is pressed or 'View Document' is clicked. I use git-annex (https://git-annex.branchable.com) and having local PDFs available as broken links initially, then fetching them is a common procedure.
I implemented a piece of code that hopefully fixes the issue for you. The code is not yet in KBibTeX's repository but only in my own one: https://invent.kde.org/thomasfischer/kbibtex/-/commits/bugs/kde470750?ref_type=heads The relevant commit is f144df19d6fd2b2f5b5a22a6ebdc3380f3edbd88. To test the new version, proceed as follows. None of the steps requires sudo/su, as all files will be stored in /tmp. 1. Get this script: https://invent.kde.org/thomasfischer/kbibtex-related/-/raw/master/run/run-kbibtex.sh?inline=false 2. Run as normal user: bash run-kbibtex.sh https://invent.kde.org/thomasfischer/kbibtex.git bugs/kde470750 Please test and confirm that this bug can be closed.
Thank you Thomas, commit f144df19d6fd2b2f5b5a22a6ebdc3380f3edbd88 fixes this for me. There's still the issue that KBibTeX seems to resolve the document path completely, getting rid of all symlinking on the way. In the case of git-annex, this is quite fatal as the target files are named after the file hashes and are completely cryptic. I think it would make more sense if KBibTeX would not resolve the path. But this probably belongs into an extra bug. 🙂
Git commit ebbfbf9f94d8bd4564642460722fadfc2dcf43dd by Thomas Fischer. Committed on 03/12/2023 at 21:15. Pushed by thomasfischer into branch 'kbibtex/0.10'. Check if 'View Document' should be enabled more often Previously, the enable status menu item 'View Document' and list of associated documents got updated when the entry selection got changed, i.e. a different entry got selected from the list. This did not take into account the possibility that a file that can be associated with an entry becomes available only after selecting an entry. There is a user-reported use case when using git-annex. This commit address the issue in the following two ways: 1. A window shortcut (QShortcut) with the same key sequence (Ctrl+D) got added, but it is disabled by default, gets enabled when the 'View Document' menu item disabled and vice versa. Activating this shortcut will first update and possibly enable the 'View Document' action and then trigger the original 'view document' code of the 'View Document' action. This is transparent to the user. 2. Whenever the context menu on top of an entry in the main list is opened, the 'View Document' menu will get updated and enabled if files to open got located that were not available earlier. FIXED-IN: 0.10.1 M +1 -0 ChangeLog M +6 -1 src/gui/file/fileview.cpp M +3 -1 src/gui/file/fileview.h M +37 -10 src/parts/part.cpp https://invent.kde.org/office/kbibtex/-/commit/ebbfbf9f94d8bd4564642460722fadfc2dcf43dd
Git commit d340c9da1b4d9196c60424642537de9e4509617d by Thomas Fischer. Committed on 03/12/2023 at 21:21. Pushed by thomasfischer into branch 'master'. Check if 'View Document' should be enabled more often Previously, the enable status menu item 'View Document' and list of associated documents got updated when the entry selection got changed, i.e. a different entry got selected from the list. This did not take into account the possibility that a file that can be associated with an entry becomes available only after selecting an entry. There is a user-reported use case when using git-annex. This commit address the issue in the following two ways: 1. A window shortcut (QShortcut) with the same key sequence (Ctrl+D) got added, but it is disabled by default, gets enabled when the 'View Document' menu item disabled and vice versa. Activating this shortcut will first update and possibly enable the 'View Document' action and then trigger the original 'view document' code of the 'View Document' action. This is transparent to the user. 2. Whenever the context menu on top of an entry in the main list is opened, the 'View Document' menu will get updated and enabled if files to open got located that were not available earlier. This commit is a cherry-pick of commit ebbfbf9f94d8bd456464246072 from branch 'kbibtex/0.10'. M +1 -0 ChangeLog M +5 -0 src/gui/file/fileview.cpp M +2 -0 src/gui/file/fileview.h M +37 -10 src/parts/part.cpp https://invent.kde.org/office/kbibtex/-/commit/d340c9da1b4d9196c60424642537de9e4509617d
> There's still the issue that KBibTeX seems to resolve the document path > completely, getting rid of all symlinking on the way. In the case of > git-annex, this is quite fatal as the target files are named after the file > hashes and are completely cryptic. I think it would make more sense if > KBibTeX would not resolve the path. But this probably belongs into an extra > bug. 🙂 Yes, please. Also, please provide a MWE so that I have a use-case to work with.