I alt-dragged a folder to a drive to create a shortcut and as I let go, the folder tree bumped up and so it went into the recycle bin as a move.
A few points here -
* Alt-Drag over any item should not be actioned as a move or copy but be blocked - a quick test suggests this occurs on Explorer but perhaps you could 'fix' it
* A Folder Bar target that changes a fraction of a second before a drop should either abort the action as unwanted or pop up a confirmation menu, if under your control. But this is a huge common fault on all windows and apps, that things pop up or shift just as you action something - even as I type this, a popup came up and took my typing as its action! - but it occurs constantly on firefox when you go to click a URL bar item and it inserts something else into the list so what you click changes to something else as you click it, and in lists (as here) where a drop target mutates as you drop an item on it... perhaps best expressed as "items should not accept relevant classes of entry/action within a limited time from their appearance or relevant change"
I think fundamentally the problem only arises when your drop target is near the bottom of the window AND the tree. You go to drop the item, but it pops open and because your mouse is near the bottom it then starts scrolling up - near the middle of the screen it pops open without scrolling, whilst a target near the bottom of the screen but NOT near the end of the tree will have already scrolled up as you went over it and you will always wait for it to settle before dropping; if it then pops open, you are at a distance from the bottom so there's no scrolling up.
* Is it possible that some extra free space of a few lines (equal to the number of lines within which a near-the-bottom-scroll will occur) could be put at the end of the tree after all items as I think that very simple change would solve the entire problem! Alternatively if the tree can be set to not scroll at all then a blank line below and above the tree (not part of the tree control) or a small overlaid box/rectangle active area top and bottom (transparent or not) could be used to make the scroll when hovered over.
I will consider free space above and below the treeview.
They should only show up when in a drag operation. But that might make the items jump up or down too much..
Thank you for the suggestion.
I will add an option to disable the auto scroll.
When disabled, you will have to use mousewheel up/down to scroll.
Many thanks!
Actually, middle button wheel scrolling during a drag already works for mine, it was added a while back. It turns out to be slightly less practical for me than you would expect because I have big fingers so it's clumsy to wheel using a finger on the same hand as the one holding down the button for the drag and I have to cross the other hand over to do the wheel, so it's more of a useful thing used sometimes rather than all the time, but I imagine for someone with more slender fingers it would work well.
If the bottom "scroll pads" were arranged, I would definitely disable the tree scrolling for drag operations and use the scroll areas, but when not dragging to the tree would still want the tree scrolling using the mouse wheel, as I use that a lot, which your comment suggests will remain the case.
In creating the free space areas it would be good if it performed a scroll speed according to where you were moused over it, so its left edge would do slow scrolling, its right edge fast scrolling, and positions between a gradient of speeds, you could control the scrolling speed, with perhaps options for the left and right edge speeds.
Scrolling is particularly helpful when dragging folders from one part of the folder tree to another part or from one tab to another tab. If you're dragging specifically from the results pane to the folder tree in theory it's easiest to get the tree in the right place first then drag on, but with the other contexts that's either not available or not visible, which "scrolling pads" would also provide a solution to. At the moment I'm one of those people who often drags something to the tree then realises it's in the wrong place, has to cancel, move the tree, then try again.
I think when the Folder Tree filter becomes implemented that will provide further avenues as you filter the tree for the target folder then drag the item in and unfilter.
Another solution to the matter of finding the target is entirely different, and might prove superior for many people - to have a "drop zone" spot where you can drop your selection temporarily and it conceptually holds onto it (adding to what is already there, which is a plus, since you can pool disparate selections into it), then (not in drag mode) you move the tree to the right place, then drag from that drop zone spot to the target and it drags the remembered files in the usual way, clearing its entries with the drop.
Although those thoughts cover two matters, they're very much intertwined issues...
