Make entry editor DND behave as specified in settings

[tobiasdiez]

This reverts commit ca2953d - and improves #5554

[tobiasdiez]

@Siedlerchr please provide a proper fix. Thanks!

[koppor]

We also need to be consistent with our documentation. Refs https://github.com/JabRef/help.jabref.org/pull/239 and koppor#368

[koppor]

I finally came up with a fix. To avoid mirroring different Linux distribution behavior, the code just checks if a modifier key is present. If not, use JabRef's setting. If yes, do what the key says. - This check was not that easy, as only the mouseEvent provides info about the modifier key and the event comes AFTER the dropped event. With some boolean flags, I could work-around.

This also fixes this preference - we seem to have missed this at the review of #5315:

[Siedlerchr]

This is in general a good idea. Could be simplified a bit more

[tobiasdiez]

Why don't you use https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/input/DragEvent.html#getTransferMode() to see if a modifier was used?

[Siedlerchr]

You can't infer from the TransferMode if a modifer is pressed. Default is copy on windows, but this could have been also triggered from a modifer key (e.g. Shift?).

[koppor]

@tobiasdiez I fully rely on #5554 (comment)

Checking for the OS does not make any sense, as it for linux depends on the desktop system the user has, and this might be different behaviors or not supporting modifiers

I did not do full research on Linux desktop differences. GNOME vs. KDE vs. LXDE vs. wmii vs. ion vs...

Maybe, a user configured his modifiers differently. Thus, just checking for modifier precense made sense to me.

[koppor]

I experimented several hours with the drag'n'drop events.

Alternative 2 is IMHO to simulate a drop event on JabRef startup and store the "normal" transfer mode somewhere. However, I do not know how to simulate a drop event.

Alternative 3 is to run a build farm where we generate Mappings for the default modifiers for each operating system and desktop environment. Pro: Mapping available at startup of JabRef. Con: If a user modifies his desktop environment, this is not covered.

[tobiasdiez]

Personally, I would let the OS decide which transfer mode is the correct one and just follow it (e.g. I don't see a reason why we should make it possible to overwrite the default drop action in the preferences...).

Alternative 3 would probably also be ok. The current approach using the key handler feels a bit hacky and I'm not sure if all edge cases are handled (e.g. user presses shift, lifts key, drops). Either way, we definitely need tests for this. This is the 4th time now that drag & drop is broken in some way.

[Siedlerchr]

The easiest solution: We simply revert to the old default behavior and get rid of those damn modifiers.
Or we completely remove the setting and use only the modifiers

[koppor]

I see the setting as follows:

The location of a PDF dragged might differ:

• A) in Downloads directory
• B) in bib directory / directories
• C) in folder shared with some team mates (dropbox or network drive)

As user:

• When I drag'n'drop from A, I want move.
• When I drag'n'drop from B, I want link.
• When I drag'n'drop from C, I want link or copy
• When I drag'n'drop, in 80% of the cases, I don't want to press any modifier key.
• In case all PDFs are in the same directory (or sorted-in properly), a move in that directory equals a link

I think, the 80% case was the reason for the drag'n'drop setting in the preferences.

For someone working alone, "move" is the preferred setting. For someone working in groups (case C), "link" or "copy" is the best default. -- Both user groups may switch to another working mode in seldom cases. Thus, the modifiers could be required.

On Windows, the default behavior matches the "copy" case for C) only. -- When I drag'n'drop from the same drive (which is case B): move. When I drag'n'drop from another drive (which are cases A and C): copy.

We cannot change the overlay while dragging. "move" appears even if something else is done. Since "move" is not the most common thing (when reading cases A, B, C). Thus, I argue that we need to keep the setting.

[tobiasdiez]

Isn't the fact that we cannot change the overlay a reason to actually remove the preference? If the overlay says "move" but it copies/links the fie, I would be very confused as a user....

By the way, your argument applied to the Windows explorer would mean that the explorer should by default only copy files from a shared / dropbox folder or that there should be an option to change the default behavior for users that often work with shared files. I guess the reason why such an option is not provided is that consistence in behavior is more important.

[koppor]

We decided to remove the preferences. The default is always link (bzw. wie das OS es halt sagt). Users will have to press modifier keys for copy or move.