Community
Participate
Working Groups
build I20060118 - in the Java perspective, arrange the left folder to have the Package Explorer and Plugins views, in that order - close the Package Explorer - show the Package Explorer - it's added to the right of the Plugins view It apparently correctly left a placeholder (otherwise the PE would have appeared at bottom right), but lost the order. This used to work, e.g. at least in Eclipse 2.1.
Is this still a problem in 3.3? PW
Yes, still a problem. In addition, the order of tabs is not preserved between sessions (which is arguable a worse problem than this one).
I would really like to see these two issues fixed for 3.3.
Let me know if I can help.
Eric, did you see anything obvious about this in your travels? It's some startup order issues between the PartStack, the IPresentationSerializer, and PresentationFactoryUtil.createPresentation(*) IIRC at the point the serializer was filling the PartStack the info wasn't available, so it ended up with a sorted list of 0 ... then actually added enough information to sort. But that was a long time ago :-) PW
This has been the standard behavior since I've been here (i.e. post-3.0). Closing a view in a stack and then re-opening it will place it at the end of the CTabFolder's list... Also, Nick's just repro'd the order change...the basic scenario was to have a set of view tabs on the bottom stack in the Java perspective (with the Bookmarks view being left-most). Open the Debug perspective then shut down, restart and switch back to the Java perspective. Unfortunately even when I follow these steps I haven't been able to cause it to happen...but I -have- seen it...
I can repro this using the new min/max... Similar scenario but simpler: Start with a clean workspace with the new 3.3 presentation on Add Bookmark view to bottom stack Drag to be left-most view shut down / restart (everything is OK) Minimize the stack Restore the stack shut down / restart (Bookmark view is now the right-most tab) Paul, I'll grab this one. The problem has been there for longer than the new min/max story but I'm in a good position to track it down...and it makes a good test case to verify that I'm managing the presentation model correctly.
*** Bug 177518 has been marked as a duplicate of this bug. ***
This is a once-off; likely an initialization rather than a storage issue. After the first restore it appears to work correctly... deferring to M7
> This is a once-off; likely an initialization rather than a storage issue. After > the first restore it appears to work correctly... That's correct for the problem in bug 177518, but not for comment 0 (which is only about reopening a closed view at the same spot). I think bug 177518 should not be a dup of this one. Comment 7 is also reproducible and should be a separate bug (since it happens across sessions and not in one session as comment 0). Separating the individual problems should also make it easier to catch these reoccurring issues in regression tests once and for all.
I filed bug 181729 for comment 7, since it is a different scenario, is new in 3.3, and requires a separate regression test.
The tab ordering cross session issues have been resolved I think (see bug 181729). The close/reopen behavior won't be addressed in 3.3. I'm not quite sure what to do to get this off my 3.3 plate; the cross session re-ordering is fixed but the original scenario is not...Comments?
If you think it may be addressed later, then just clear the Target Milestone, and maybe mark it as Resolved > Later if you want it out of your bucket. Otherwise, just close as WONTFIX. While I liked the old behaviour where it remembered a placeholder when you closed the view, I'm not going to argue about it.
Nick , upon checking around it turns out that the 'always open as right-most tab' may be intentional; it's more deterministic than inserting the view into the tab list at some other (potentially arbitrary) location. I've moved bug 177518 to a more accurate defect, leaving this one free to be determined post-3.3 and changingthe target accordingly...
*** This bug has been marked as a duplicate of bug 181729 ***
