-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shift-drag behaviourisms #161
Comments
Easing the shift-drag-replacement animation could help to avoid clutter. |
Yes, this drag logic using jquery-ui sortable is old and insufficient to intent. There are examples in the jquery-ui documentation that do most things right. I've studied these but not found the combination that works. https://github.com/fedwiki/wiki-client/blob/master/lib/refresh.coffee#L49-L115 A good model is the way the mac finder column browser works, especially how it distinguishes copy from move by showing a green plus sign over the item being moved. Shift here reverses the decision that the browser has already made. This idiom dates back to Xanadu. https://en.wikipedia.org/wiki/Miller_columns |
If I remember correctly, there are a number of assumptions that made in jQuery-ui sortable that make it difficult, if not impossible, to mix the drag to move and shift-drag to copy. The only jQuery drag a copy examples I have seen use draggable. This is very probably an area where a native HTML5 solution could well be easiest HTML Drag Operations - but are likely to require some extensive changes to the client code. Couple this with other desirable client changes this will likely be easiest to do as part of a rewrite. |
@paul90 Thanks for pointing this documentation out. We could learn a lot from some use-case specific and federation-compatible rewrites. A read-only version or a touch-specific version come to mind. The addition of one extra layer of div (.paper) was fraught with complications. I suspect redoing drag/drop would be equal, but maybe no worse. |
The shift-drag is intended well, but its current implementation retains few glitches:
Were these accepted as those and documented before?
Else both could become individual issues and this closed.
The text was updated successfully, but these errors were encountered: