Drag'n'drop item to end of an SvTreeListBox

[Jan-Marek Glogowski]

Hi Brian,

Am October 10, 2018 4:02:09 AM UTC schrieb Brian Fraser <brian at softfrog.ca>:
>Hello,
>
>I'm working on drag'n'drop support for reordering animations in Impress
>(the CustomAnimationList UI element, which inherits from
>SvTreeListBox). I
>need to support dragging an effect to below the last effect in the list
>in
>order to move it to the end of the list.
>
>I'm overriding the NotifyMoving(...) function to get notifications of
>when
>an effect has moved. It tells me which effect was dragged, and over top
>of
>which effect it was dropped. I can then move the effect above the
>target in
>the tree to reorder it. However, this does not support dragging 'n
>dropping
>the effect to the end of the list, as dropping it past the last effect
>has
>NotifyMoving() tell me it's target is the last element in the list (and
>hence goes above it).
>
>Is there a good way to resolve this?
>
>I have a couple ideas which I would welcome comments on:
>1. Create a blank 'fake' entry at the end of the list when dragging
>starts.
>If NotifyMoving() tells me it's target is the fake, I know to put it at
>the
>end (and remove the fake when done).
>
>2. If an effect is being dragged 'up' the list, put it above the
>target; if
>it's being dragged 'down' the list, put it after the target. This might
>be
>confusing to the user as the above/below behaviour would be context
>specific. This might be less jarring if I were to also incorporate an
>animation effect on the UI to show where the moving effect will appear.
>(Suggestions on this are also of interest!)

The extended 2nd idea would be my preferred solution. If you already move the element while dragging in the tree the feedback is easy for the user to understand. You move the pointer up to the previous item, and that item moves down, you move it down to the next item and the below item moves up.
It gets trickier, when you want to combine this with scrolling, i.e. when you want to reach an item not currently displayed.

So my idea for scrolling would be: you put the pointer out of the current the list or near enough to the border, depending on the relative position, you do
* in a position relative to the orientation direction, i.e. if you're list is horizontal, the pointer is to the left or right, you start scrolling, speed adapting to the distance to the list
* otherwise you remove the item from the list.

OTOH Gtk+ used to show an arrow on the popup menu, if it didn't fit on the screen, so you could "scroll" it by moving the pointer in that area; probably it still does.

While in the list you just make sure the dragged element is always moved where the pointer is. Probably also while scrolling, so the item stays at the same end of the list where the pointer is.

If you want to implement copy / cut and paste, I don't think there is a always working solution. And without direct user feedback, always moving items up or down feels more consistent to me.

I mixed list and tree in the text; these ideas should be applicable to both.

HTH

Jan-Marek