Hi Brian,
Am October 10, 2018 4:02:09 AM UTC schrieb Brian Fraser <brian@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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.