Link a directory to entries

Features
1

Dear all,

I would like to link a directory to an entry. Of course, JabRef should launch a file explorer when opening the directory.

My idea is to keep everything related to the entry in this directory: the main file(s), notes, etc.

I haven’t found a way to do that on the UI. If I edit the file field outside JabRef and put the directory name, it works but then I have troubles with rename rules.

IIRC, it was working on older versions but I might be wrong.

Any idea?

Thanks in advance,
Mathieu

2

Just wanted to know if somebody has an idea on that.

3

What version of JabRef are you using? What older version was working?

4

Hello,

Thanks for your answer.

I’m using version JabRef 5.15--2024-07-10--1eb3493 (from brew). I’m sorry but I can’t remember what version was working: it was several years ago so I would say around JabRef 3.

Just to be clear: I initially configured JabRef to put linked files in a specific subdirectory of the main directory (with the key as pattern) so files end-up in Content/[bibkey]/[bibkey].ext but I would like to link the directory Content/[bibkey]/.

5

If it is not possible and if the crowd wisdom think it’s possible, do you think it would be hard to implement by, say, someone totally outside of JabRef development (with limited knowledge of Java) ? I took a look at JabRef development process and while it seems very professional, it’s a bit heavy for newcomers.

6

Do you mean that it should open a file picker to the directory or open the file explorer application? Note that if the entry has a linked file, you can open the directory with the shortcut Ctrl+Shift+O.

I think this is beside the point, but remember that you can also edit the file field directly in Jabref using the “Bibtex source” tab or through find and replace. Obviously, this doesn’t help keep the directory name in sync with the citation key. Then again, if find-and-replace supports regular expressions, you could replace (Content/[^/]+?/).*\.ext with $1 periodically to remove the file name from the path.

I am not sure what currently happens to the subdirectory name when a citationkey changes. Is the fundamental issue that the directory name does not change to match?

7

Sorry for the delay, the notification ended-up in spam.

I know (and use) the shortcut you talk about but this is not exactly what I have in mind.

What I have in mind is that the folder itself is the linked “file” so clicking on it opens the file explorer (in the same way that if a PDF file is link, clicking it opens the PDF reader application).

Therefore (and this partially answers the second part of your message - which is a nice trick BTW), changing the key should rename the directory (without changing files in it).

8

In that case, clicking would perform the same function as the keyboard shortcut, and only the GUI would need to change to implement this part of your idea. A few possibilities come to mind for me, and I do agree that linking to a directory would be nice.

  • Add a “Linked folder” field to the entry table (optional column) that behaves exactly like the “Linked files” field, but has a folder icon instead of an attachment.
  • Add another icon to the Linked files field to show a linked folder (considering that the icon already changes between PDF, multiple-attachments, link, and I think also a globe for URLs).
  • Consider adding “Open containing folder” to the options when hovering over a linked file (the popup that currently lets you choose which attachment to open)
  • Don’t change the GUI, but add an option in preferences to “Open containing folder instead of linked file”.

I don’t know what would need to change for the file picker to allow selecting a folder instead (and I did not use or don’t recall the old functionality that you mentioned). Take my opinion as an educated guess, but your idea seems very attainable to me, because it does not involve any fundamentally new functionality or user behaviour.

  • The entry table already has optional columns and clickable icons
  • There is already a “home” in “Preferences” and “Library > Properties” for preferred paths and patterns, including library-specific and user-specific options.

My observation is that if an idea has merit, is not too difficult, does not require radical changes, and is clearly described, there is a reasonable probability that someone will implement it.

My own development capability fits your description, or might be less if you work as a developer in another context. I had no difficulty following the instructions for setting up IntelliJ, but left it alone after the initial setup to get acquainted with git. Time is short, unfortunately, and the only “code” I have contributed so far is a couple lines of CSS.

I have noticed that the maintainers answer lots of questions in the developer chat on Gitter as well as in pull requests. There are lots of students participating and it is common to see hints pointing beginners in the right direction.