Bug 470750

Summary: 'View Document' should check for existance of local PDF at keypress, not on list build
Product: [Applications] KBibTeX Reporter: nobodyinperson <nobodyinperson>
Component: User interfaceAssignee: Thomas Fischer <fischer>
Status: CLOSED FIXED    
Severity: normal    
Priority: NOR    
Version First Reported In: git (master)   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 0.10.1
Sentry Crash Report:

Description nobodyinperson 2023-06-07 15:26:14 UTC
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.
Comment 1 Thomas Fischer 2023-11-24 16:36:32 UTC
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.
Comment 2 nobodyinperson 2023-11-24 17:51:41 UTC
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. 🙂
Comment 3 Thomas Fischer 2023-12-03 20:15:49 UTC
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
Comment 4 Thomas Fischer 2023-12-03 20:23:06 UTC
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
Comment 5 Thomas Fischer 2023-12-03 20:24:03 UTC
> 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.