use HTML Drag and Drop API [WIP] #771
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This follows the conventions of the HTML5 drag-and-drop API, and replaces the _extraAllowableChildTargets property.
This replaces the long-title branch and pull-request.
Some tweaks when really low on space and dropdownActive: Don't overlap tabs too much, unless needed for active tab.
Numerous problems still to fix.
When a drag starts we disable pointer-events in iframes so we can we can follow mouse and drag events. The complication is when the drag starts in one top-level window, but drag-over freedback and possible drop cn happen on other top-level windows. This change provides a event-hook that applications can use to notify other windows. Also some other minor tweaks.
This uses new drag-enter-window and drag-leave-window events which can be used to track if pointer is in a window and hence whether drop was to a window or to desktop.
Usuallu typing Esc during a drag. Should restore pre-drag state.
This is used to position windows after "drag-to-desktop".
Remove the lm_headers element and back the header children of the stack element. The is safe now that a moved tab is hidden but not removed until dragend. Create a lm_item child under lm_items for each component. This makes it easier to set position out-of-item-tree components even it lm_items has border and padding. Various related simplifications, including item.element is now always meaningful (the lm_item child of lm_items). We can ignore contentInset setting in position calculations; instead we just use it to set item margin. Remove VIRTUAL_ELEMENT_DUMMY static - just use undefined. New contentItem.createElement convenience function.
Add a "background" child of the lm_splitter element. Make the background wider than the splitter, but use negative z-index. On dragging move the drag-handle only.
We would sometimes get a race where the dragenter would be called before we removed/hid the dragged component in the requestAnimationFrame (called by the dragstart handler). This could cause calculateItemAreas to be wrong.
This allows more flexible positioning of lm_goldenlayout element. For example it can follow a titlebar or menubar without neeeding to be nested in an extra container. Also nest droptarget-indicator within lm_goldenlayout element, to avoid less clutter in the top-level body.
Also make old non-drag logic (if useDragAndDrop is false) work again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a usable prototype using the HTML drag-and-drop. It supports (with some glitches):
I have not tested "virtual components" - but they are less needed because I changed things so non-virtual components are allocated under the top-level
body, not the in the item tree. (I'm still interested in using virtual components to control widgets that are separate windows but that has to wait.)The code needs work and the API is not stable. There are some incompatibilities - code written for the GL 2.x will not work, though it should be possible to fix that.
This builds on the 'tab-renderer' branch (PR #759).
This is used by the
drag-dropbranch of DomTerm.