Community
Participate
Working Groups
I20120814-0800 Drag and Drop of view tabs to/from tab groups behaves unpredictably. It doesn't even look deterministic. Sometimes, there's no drop target, and sometimes, it drops at the wrong position. Here's how it should work: - When you drag a view tab, a drop target must appear before and after each view tab in all tab groups (i.e. also at beginning and end of a tab group). For consistency and immediate feedback, a drop target should also be available at the left and at the right side of the original tab position (dropping there is a no-op). - The tab must be inserted at the drop target position. - When a view is dragged out of a tab group, the next view in MRU order (Ctrl+F7) must come to front. Currently, the view on the left of the dragged tab comes to front.
Markus, can you give me a way to reproduce the problem with the tab being dropped at the wrong location ? I've just tried it (a bit) and haven't seen a case yet where the result doesn't match the given drop target affordance (which I agree could be better). Also, why does it matter whether it's the one to the right vs left in the MRU order when you drag a tab out of a stack ? The order of views in a stack is essentially random (i.e. they're in whatever order they were originally opened in). Overall I'm not very happy with the current DnD implementation myself and would love to spend a few weeks getting it 'right'...weeks I unfortunately don't have.
Created attachment 220144 [details] Screenshot It's hard to describe, since I don't know the conditions that cause the bugs. A bug that show up most of the time: Start dragging a tab and move the mouse a bit to the left, so that the green bar appears on the left of the dragged tab. If you drop there, then the view should keep its position, but in fact it's moved to the left by one tab. Another problem that I can reproduce with the setup shown in the screenshot: Try to move the Problems tab after "Plug-in Dependencies" => no green bar (but dropping there does move the tab correctly. After playing with this for a while, I think this bug depends on the width of a tab. The missing green bar after "Plug-in Dependencies" can also be observed if you add the Tasks view at the end of the group.
> Also, why does it matter whether it's the one to the right vs left in the > MRU order when you drag a tab out of a stack ? Mostly for two scenarios: a) You open a new view and then move it away since it didn't appear in the tab group you wanted it. Then you have to restore the front tab again. b) You open a view (e.g. Search), then you check the results and close the view again => previous view should be on top again (like when you open an editor and then close it again). > The order of views in a stack > is essentially random (i.e. they're in whatever order they were originally > opened in). In 3.8, the order is the MRU order, which is not random.
Got you...it's not a 'left / right' issue it's that the whatever tab was last active in that stack should be the new 'selected' one. Perhaps we can use the PartActivationHistory, I'll see if I can match the way that we do it when you close an editor. As far as the feedback goes I'll be reviewing this completely in any case (there have been more than a few 'suggestions' that it bites...;-).
Let's use this bug for the bad drop feedback (green bar) and the wrong location of the tab after dropping. Bug 387876 is for the wrong tab coming to front after moving a part away (should be next in MRU order).
+1 sounds good to me...
I can reproduce it consistently. Steps to reproduce: 1. Create new workspace. 2. Open several views (in my case Console, Progress, Tasks, Error Log). 3. Detach Error Log so that it gets its own window. 4. Drag Error Log back to the main window and try to drop it in its previous position. => Error Log is dropped always as a 5th view. The green "drop here" bar is somehow inconsistent because sometimes it drops the view before and sometimes after the bar.
I think I got this fixed. I will submit a patch after I write an automated test for it.
Thanks Piotr, I've been meaning to get to this but there's always something else on the top of my plate..;-(.
Created attachment 224998 [details] patch v.1 Due to being overloaded with work I haven't managed to write the automated test and decided to submit a partial patch (just the fix with no test). Perhaps someone can review if the fix makes sense while I write the test.
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=a0c375018d74ecb34887eafb9cc7195863e39dbf This applies Piotr's fix (Thanks a lot!) which fixes the 'drop at end' issue. Next on the list is to fix the 'move left when should be no-op issue' identified by Markus. Then I'll likely also turn the 'thin line' into something more visible like a triangle...
git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=199ab609222078e2e3f0a8c00c3dfc275ea8cc5f Fixes the 'move left' issue reported by Markus I'm going to move this defect over to 4.2.2 since I've committed against the maintenance branch...
Eric, is this fixed or should it be moved to 4.3? PW
Verified in latest 4.2.2 and 4.3 builds. I could not reproduce any of the mentioned problems any more (except for bug 387876).
Thanks Markus, I'll be looking into bug 387876 for 4.3...
