Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"General file directory" is not respected when dropping a file #8179

Closed
2 tasks done
koppor opened this issue Oct 24, 2021 · 8 comments · Fixed by #8181
Closed
2 tasks done

"General file directory" is not respected when dropping a file #8179

koppor opened this issue Oct 24, 2021 · 8 comments · Fixed by #8181

Comments

@koppor
Copy link
Member

koppor commented Oct 24, 2021

JabRef version

Latest development branch build (please note build date below)

Operating system

Windows

Details on version and operating system

Windows 10

Checked with the latest development build

  • I made a backup of my libraries before testing the latest development version.
  • I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

  1. Library properties: Set pdf/ as directory
  2. Drag'n'drop a PDF onto an entry
  3. PDF is attached to the entry
  4. PDF is put in the directory of the .bib file

Expected behavior:

PDF is put into pdf/ sub directory

Notes

  • Note that the PDF still opens. Maybe some magic at JabRef's file open behavior?
  • If the PDF is moved into pdf/, the PDF still opens

Related Issues

@Siedlerchr
Copy link
Member

Siedlerchr commented Oct 24, 2021

Did you uncheck "Search and store files relative to lbrary file location"?
Did you use a modifier key? https://docs.jabref.org/advanced/entryeditor#drag-and-drop-behavior-settings

Codewise

this.setOnDragDropped(event -> {
BibEntry entry = this.getEntry();
boolean success = false;
if (event.getDragboard().hasContent(DataFormat.FILES)) {
List<Path> files = event.getDragboard().getFiles().stream().map(File::toPath).collect(Collectors.toList());
switch (event.getTransferMode()) {
case COPY -> {
LOGGER.debug("Mode COPY");
fileLinker.copyFilesToFileDirAndAddToEntry(entry, files);
}
case MOVE -> {
LOGGER.debug("Mode MOVE");
fileLinker.moveFilesToFileDirAndAddToEntry(entry, files);
}
case LINK -> {
LOGGER.debug("Mode LINK");
fileLinker.addFilesToEntry(entry, files);
}
}
success = true;

Log level debug should show which action is executed.
#5105 is not related!
And #7152 was a wording issue.

@koppor
Copy link
Member Author

koppor commented Oct 24, 2021

Did you uncheck "Search and store files relative to lbrary file location"?

No (meaning "Search and store files relative to library file location" is checked). Nevertheless, the concrete setting of a library should overwrite the general JabRef setting.

Did you use a modifier key? docs.jabref.org/advanced/entryeditor#drag-and-drop-behavior-settings

No. The file was moved.

@Siedlerchr Siedlerchr added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Oct 24, 2021
@Siedlerchr
Copy link
Member

@koppor We recently talked about this in the latest dev call. And that's why the tooltip has been added. "It takes precedence over all other settings"

@koppor
Copy link
Member Author

koppor commented Oct 24, 2021

Let's re-iterate on that tomorrow again.

Screenshots:

Global setting

grafik

Local settings

grafik

@Siedlerchr
Copy link
Member

Solution: Change to Main File Directory and do not enter any value,

/**
* Look up the directories set up for this database.
* There can be up to three directory definitions for these files: the database's
* metadata can specify a general directory and/or a user-specific directory, or the preferences can specify one.
* <p>
* The settings are prioritized in the following order, and the first defined setting is used:
* <ol>
* <li>user-specific metadata directory</li>
* <li>general metadata directory</li>
* <li>preferences directory</li>
* <li>BIB file directory</li>
* </ol>
*
* @param preferences The fileDirectory preferences
*/
public List<Path> getFileDirectories(FilePreferences preferences) {

@koppor
Copy link
Member Author

koppor commented Oct 24, 2021

/**
* Look up the directories set up for this database.
* There can be up to three directory definitions for these files: the database's
* metadata can specify a general directory and/or a user-specific directory, or the preferences can specify one.
* <p>
* The settings are prioritized in the following order, and the first defined setting is used:
* <ol>
* <li>user-specific metadata directory</li>
* <li>general metadata directory</li>
* <li>preferences directory</li>
* <li>BIB file directory</li>
* </ol>
*
* @param preferences The fileDirectory preferences
*/
public List<Path> getFileDirectories(FilePreferences preferences) {

The settings are prioritized in the following order, and the first defined setting is used:

  1. user-specific metadata directory

For me, this is

grafik

  1. general metadata directory

This IMHO is following directory

grafik

--> The code comment should be updated to reflect the wording of the settings dialog

  1. preferences directory

This is the choice between these two

grafik

  1. BIB file directory

This explains why the file can still be opened

@Siedlerchr
Copy link
Member

Siedlerchr commented Oct 24, 2021

Following order:
Option 1: Library -> user specified file directory
Option 2: Library -> general file directory
Option 3: Preferences directory : Main file directory
If Option 4 is used, then it takes precedence over all others!
Option 4 refers to the old "use bib file location as primary directory" (I liked that wording better!, now )

@ThiloteE
Copy link
Member

As a side note, is it possible to make the difference between main file directory and general file directory more clear? Both names sound too similar and can easily be misinterpreted. Or do they actually do the same thing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants