feat: restore tab reorder on drag-drop, add split-on-edge zones#3762
Merged
kasemir merged 1 commit intoControlSystemStudio:masterfrom Apr 2, 2026
Merged
Conversation
Let DockItem's original name_tab handlers manage tab-on-tab drops (same-pane swap and cross-pane insert-after) by not consuming DRAG_OVER events in the tab header strip. DockPane's capture-phase filters now only consume events below the tab bar, where they handle centre-zone merge and edge-zone split. Follow-up to ControlSystemStudio#3759 (split DockPane on edge drag-and-drop).
|
Collaborator
|
In first tests it works very well, thanks! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Restore tab reorder on drag-drop, add split-on-edge zones
Summary
Follow-up to #3759 (split DockPane on edge drag-and-drop).
PR #3759 introduced capture-phase
addEventFilter(DRAG_DROPPED)onDockPaneso that edge-zone splits could intercept drops before child nodes consumed them. A side-effect was thatDockItem's existingname_tabdrag handlers — which implement same-pane tab reorder (swap) and cross-pane tab-on-tab insert with green-border / green-text visual feedback — were blocked from ever receiving events.This PR restores tab reorder by letting those original
DockItemhandlers work again, without removing the split-on-edge functionality.What changed
Only
DockPane.javais modified (56 insertions, 36 deletions).DockItem.javais unmodified — the tab-on-tab reorder uses the original upstream implementation as-is.Approach
DockPane's capture-phaseDRAG_OVERfilter now does not consume the event when the pointer is inside the tab header strip (y ≤ tab_bar_bottom). This lets the event continue toDockItem's bubble-phase handlers onname_tab, which:For all other positions (pane body, empty tab-bar space, edge zones), the filter consumes as before and
DockPanehandles:The
DRAG_DROPPEDcapture filter uses a lightweightisOverTabNode()helper (walks up from the pick result looking for a.tabCSS class — typically 3–5 parent nodes) to decide whether to delegate toDockItemor handle the drop itself.Behaviour summary
Known issues
Window focus loss after cross-pane drag-and-drop (pre-existing)
After completing a cross-pane tab drag, the target window can appear to lose OS-level focus — the title-bar close button may not respond to hover until the user clicks once inside the window. This is a pre-existing upstream issue present in the official Phoebus 5.0.2 release (tested on KDE/X11 with JavaFX 21).
JavaFX internally reports
focused=truewhile the X11 window manager disagrees, soWindow.requestFocus(),Stage.toFront(), and similar workarounds have no effect. This PR does not attempt to fix it to avoid adding fragile platform-specific hacks.