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.
Summary: | Use arrow for reordering tabs | ||
---|---|---|---|
Product: | platform | Reporter: | _ gtzabari <gtzabari> |
Component: | Window System | Assignee: | issues@platform <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | BernTal, dynamite, k776, mmirilovic, rroska |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 70468 |
Description
_ gtzabari
2006-08-23 05:32:53 UTC
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. |