Community
Participate
Working Groups
If you grab a view tab and drag it from one frame to another, you can: 1) drop the tab on top of another tab to insert it in front of the tab you dropped on (with the target tab outlined to indicate what will happen), or 2) put it at the end of the existing tabs with an outline of a "phantom" tab indicating that tab will be added at the end. However, if you drag a view tab to the end of the *same* frame it is already in, you do not get the "phantom" tab outline to place the tab at the end. Instead, you must drop on the last existing tab to to get the dragged tab to move to the end. Not only is this inconsistent with the frame-to-frame behavior, it makes it impossible to place a tab in the second to last position in the same frame. I would expect a "phantom" tab outline in all cases. Note that this problem also affects the editor tabs.
I think an insertion point indicator would work better than a rectangle around the tab.
The rectangle appears around the area where the tab will be dropped. In the case of dragging to a different folder, you see the "phantom" tab since dropping at the end will create a new tab. In the case of dropping in the same folder, you do not see any phantom tab since dragging the tab to the end will place it in the location currently occupied by the last tab. The options: 1. It would make sense to show the entire outline of the folder with the correct tab size to make it clear that you're seeing an outline of where the tab will be dropped rather than having it appear as though it is simply highlighting the tab you're dragging over. 2. Alternatively, we could take Nick's suggestion and use a point indicator rather than an outline. Personally, I prefer option 1... but we can let the usability experts figure this out. Option 1 would require adding a StackDropResuilt(Rectangle[], Object) constructor and a corresponding Rectangle[] getSnapRectangles() method. Option 2 would require adding a new callback interface that allows for presentation-defined dragover affordances -- that way we could leverage SWT's CTabFolder.setInsertMark API. However, to do this properly we'd also need a way to hide all the rectangles in an active Tracker without closing it (if we're showing an insertion mark, we shouldn't also be showing the rectangles). API-wise, it would make sense to offer both. Neither enhancement will be added for version 3.0. However, for 3.0 it might make sense to change the size of the drag-over rectangle to make it clear that you're seeing the outline of the tab you're dragging, not the outline of the tab you're dragging over.
After further experimentation, I have discovered the root inconsistency. If you drag a tab to move it to another position in the frame it's currently in, it is placed *after* the outlined tab. If you drag a tab to another frame, it is placed *before* the outlined tab. This is confusing, and certainly not obvious. I see two solutions: 1. (best) Nick's suggestion to show the insertion point is both the most common (in my experience) and the most intuitive. It's hard to imagine someone not immediately grasping what will happen when they let go of the tab. 2. Pick either "before" or "after" for the dropping behavior w.r.t. outlined tabs and always do it that way, regardless of same-frame or frame-to-frame dragging. Ideally, "before" would be chosen, as it is a more common convention. As for showing the entire outline of the folder with the correct tab size, I don't see how that fixes the core inconsistency of before vs. after.
It would make sense to use an insertion marker, but this requires API changes. Investigate for 3.1.
Remy is now responsible for watching the [ViewMgmt] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
