This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Please consider adopting the same UI as FireFox whereby a small arrow denotes the insertion position when changing the order of tabs. The current UI (red border outline) is great for when one wishes to dock a document to the side of the screen because it emphasizes the bounds of the new container but it is a poor match for simply repositioning tabs. The small arrow is a good match because it emphasizes an exact position (insertation point) as opposed to an entire border which isn't relevant when reordering tabs. Also, I find that the current UI is difficult to use across remote-desktop where drawing the border is rather slow as opposed to drawing the smaller arrow.
I agree with reporter, it would be better (and hopefully faster)
the firefox "situation" is much more easier. You cannot redesign WS in firefox. In NB you can either move tab into new position in tab group or you can move the whole window to new position. OTOH, indication of drop position between tabs would be useful.
The primary problem I am trying to solve is how awkward it is to drag-n-drop. I find the existing mechanism is too "shaky". I would suggest experimenting with the following approach: 1) Get rid of the preview thumbnail. It blocks my view so I can't see where I'm dropping the item. 2) Use arrows to indicate tab-drop positions 3) When a "large drag" operation begins (i.e. move a tab into its own pane), outline all possible drop positions (everything except arrows) in some neutral (gray?) color as if they are unfocused. When the user drags the mouse over a possible target, shift its color to some primary color (red?) to indicate it gains focus. If the user drops the item, it gets dropped into that target. 4) Large drop position discussed in #3 should not intersect the arrow drop positions. That is, if I drag the mouse over the horizontal span of tabs, the arrows should display. The red drop target should only display *below* this span so there is no ambiguity that dropping inside the span orders tabs whereas dropping outside it changes panes. Right now you will notice that dragging a tab into a new "top pane" will highlight an area that includes the tab-span.
This is the only remaining item blocking issue #70468. Can you please re-evaluate this issue?
AFAIK it's not on our plan, not enough resources, sorry. Patches from community are welcome, as always.
*** Bug 189484 has been marked as a duplicate of this bug. ***
*** Bug 104838 has been marked as a duplicate of this bug. ***
*** Bug 68536 has been marked as a duplicate of this bug. ***
*** Bug 166447 has been marked as a duplicate of this bug. ***
core-main 6676cd44c53f The default shortcuts are Ctrl+Shift+Alt+Left and Ctrl+Shift+Alt+Right
Please reopen this issue. I have two outstanding complaints: 1. The bulk of my complaint was about reordering tabs by mouse, which is not fixed. 2. The keyboard binding is too long and frankly I don't think we need a keyboard binding for this operation.
(In reply to comment #11) > Please reopen this issue. I have two outstanding complaints: > > 1. The bulk of my complaint was about reordering tabs by mouse, which is not > fixed. > 2. The keyboard binding is too long and frankly I don't think we need a > keyboard binding for this operation. Please file new issues, thanks.
Filed issue 228632. Thanks.