SUMMARY After you import a new item via paste, resulting in the selected element automatically changing, this element selection can get "lost" internally, so that ctrl-d will open the document for the previously selected element, ctrl-e will edit the previously selected element. This affects the Element menu item as well. STEPS TO REPRODUCE 1. Open KBT and create a new document. Add a new element. I added a journal paper using the DOI. 2. Add a local PDF to the newly created element. Make sure that the element is selected, and check that ctrl-d opens the PDF as expected. 3. Copy a BiBTeX citation to your clipboard in another application. I copied a citation from KWrite, downloaded from a Google Books page. 4. Paste the citation in KBT by pressing ctrl-v. 5. Observe that the newly created element for the pasted citation is selected in KBT. Click the Element menu item to open the menu. 6. Observe that there is no sub-menu for "View Document", because there is no local file corresponding to the newly created element. Close the sub-menu **by clicking on the Element menu item again**. 7. Observe that in the interface the newly created element remains selected. Immediately press ctrl-e. OBSERVED RESULT The editing window for the **first** element created in the reproduction steps is opened. If you click on the Element menu item, the View Document option will give access to the PDF file, and ctrl-d will open it. In other words, KBT acts as if the wrong element were active in the element selection panel. The true selected element has been lost. This somehow happens *after* the menu is opened in step 5. EXPECTED RESULT The editing window for the newly created element is opened. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.9-arch1-1 (64-bit) Graphics Platform: Wayland Note: my distribution builds KBT against Qt 5, not Qt 6.
I am having trouble reproducing the described problem *sometimes*, i.e. sometimes I get the result you describe, sometimes not. I suspect the issue you describe is cause when the information what is selected (no, one, or several lines) diverges from what is the 'current' line. Maybe there is a deeper problem or a bug in Qt, but it seems to suffice to set the current line to be one of the selected ones (if there are any) when the main list receives focus after closing the menu. Please let me know if this commit fixes your problem: https://invent.kde.org/thomasfischer/kbibtex/-/commit/7790859456a50ff8e31e918da2835b03cda51075