Sort dictionaries by drag and drop v2

[aexiting]

Mentioned this in the commits. But this is work to allow users to short their dictionaries using drag and drop.

Based on the nature of dragover we can't really stop it from firing while in a valid drop area. So the second best thing is using the preventDefault() function in the dragover handler and putting most of the logic on the drop which will happen once. That should be more efficient.

This is my first contribution so any feedback would be helpful. I typically use React and typescript so the OOP coding paradigm took some adjustment. Fixes: #796

[github-actions]

✔️ No visual changes detected by playwright.

[StefanVukovic99]

Thanks for the PR! I've tried it and it works.

It's kind of hard to tell where the dropped dict will get sorted. Here I try to put the 1st dict in between dicts 2 and 3, but it goes to 3:
Screencast from 04-25-2025 04:55:56 PM.webm
Similarly, if I try to 'cancel' the drag-and-drop, by dropping an element over itself, it will get lowered by 1 position if I happen to drop it on the lower half, and if i try to move it up, it won't work unless i go to the upper half of the dictionary above. I think all the targets should be moved one half element down. If that is fixed, and there is some visual indication that the dicts are drag-and-droppable, I think that might be enough for this PR.

It would also be nice if the dictionaries got scrolled when trying to drag out of the box, but not sure if this is a must-have:
Screencast from 04-25-2025 04:56:20 PM.webm

And ideally, we would have the elements move so you always know exactly where it will end up when dropped:
Screencast from 04-25-2025 05:09:42 PM.webm

[aexiting]

I think I fixed some of the issues you mentioned with the previous commits. @StefanVukovic99 I could move the logic of updating the sorting to happen ondragover but in a previous commit you said that it caused efficiency issues since ondragover is called constantly while dragging.

[Kuuuube]

A few things from a quick look:

1. Is is possible to get this working on mobile? It seems to just do nothing when I tested it there.
2. It would be nice if when dragging there could be a highlighted line that shows the position the dict is going to be put. (we already have separator lines so maybe a color change/bold sort of thing there)
3. Is there any way to cancel after dragging? Hitting esc or right clicking just drops it normally instead of canceling.
4. It might be a good idea to style the currently dragging entry differently. Stefan mentioned actually having it move positions as you drag. But I think for now even something as simple as lowering the opacity would be good so it's clearer which dict has been picked up.

[aexiting]

A quick update:

1. Still trying to get it to work on mobile.
2. To make it clearer where you've placing the dictionary, I've updated it so that the dictionary being dragged will have 50% opacity.
3. I've also added a highlight to the entry that will be replaced if you were to drop the dictionary.
4. So, in the case you want to cancel the drag you can just place it back in the spot it was originally. That will cancel the drag.

[YukiNagat0]

Am I correct in understanding that the current implementation in this PR allows the entire dictionary row area to trigger drag-and-drop functionality?
If so, this might present a usability concern. For example, if a user wants to copy the dictionary name from the menu, the full-row drag zone could interfere with text selection.
Would it be possible to constrain the drag-and-drop initiation to a specific area within the row (like a handle icon or designated area) instead?

[Kuuuube]

2. To make it clearer where you've placing the dictionary, I've updated it so that the dictionary being dragged will have 50% opacity.

Looks great.

3. I've also added a highlight to the entry that will be replaced if you were to drop the dictionary.

This is good but I think it would be more intuitive to only have the border on the top. That way only the part where it's going to "slot in" is shown and it's unambiguous whether it's going to go in above or below.

4. So, in the case you want to cancel the drag you can just place it back in the spot it was originally. That will cancel the drag.

Considering right clicking or hitting esc cancels a drag on nearly every other program that has dragging I think we probably need that here. It's not particularly nice to have the item dropped where it is instead of canceling the operation when either of these are pressed.

Also I'm in agreement on needing to constrain the area for dragging. Just using the arrow up/down icon youve added should be fine for the zone.