Community
Participate
Working Groups
I20100716-1834 1. Wipe your deltas. 2. Point your Eclipse at your 4.0 workspace (which should have code from CVS naturally). 3. Window > Open Perspective > Other... > CVS Repository Browsing 4. Ctrl+F8 > Java 5. Open some file under version control. 6. Right-click > Team > Show History 7. Nothing happens. 8. Ctrl+F8 > CVS Repository Browsing 9. Right-click > Team > Show History 10. It works here. :( The workaround is to just show the 'History' view in the perspective before you try to use the menu item. The root cause is bug 315133 but fixing that for RC3 requires a lot of changes in my opinion (haven't done a full assessment but this is my gut feeling).
this one has been bugging me for some time because I hit it *all the time* in my day to day workflows. Once you know the workaround, life can continue, but the first time it happened to me it made me think that things were very unstable or broken, and I didn't think to do "show view" until I thought about the implementation. It's not intuitive to a regular user.
Created attachment 174677 [details] WorkbenchPage patch v1 Instead of just activating the part, we ask the part service to show the part. This ensures that the part will be brought up.
(In reply to comment #2) > Created an attachment (id=174677) [details] > WorkbenchPage patch v1 Paul, please take a look.
Susan, please approve for RC3 candidate.
+1 for RC3. I assume Paul is giving the OK on the code itself. I examined the patch and AFAICT, the show part (specifically the addPart processing) is what the user workaround (explicitly showing the view) was doing, which is good. Paul can assess the risk...
OK, looks good. PW
Fix released to HEAD. I took the liberty of inlining a comment to explain the change.
Uh-oh, if you Ctrl+F8 back you'll notice that the 'History' view is now missing from the 'CVS Repository Browsing' perspective. :/
Created attachment 174835 [details] WorkbenchPage patch v2 Delegate to the 4.0 code instead of the EPS. This will allow the references and placeholders to be sorted out prior to attempting to show the part. The problem was that when the part was shown in the original perspective, it simply dragged its original placeholder from the other perspective instead of spawning a new one which caused the other perspective to no longer have the view up.
Paul and Susan, will need new +1s I'm afraid.
This looks good and makes sense. PW
The code looks a bit Greek to me (I've not had to delve into the inner workings of part management, secondary id, etc....). But - Paul says it's OK - I'm +1 that we should fix this for RC3 - tested the patch and verified it solves the problem - Ctrl+F8 is working in this scenario Paul - if you think another knowledgeable reviewer should have a look at the patch, please say so (as I don't think I'm knowledgeable enough to count).
(In reply to comment #9) > Created an attachment (id=174835) [details] > WorkbenchPage patch v2 Delivered to HEAD with an NPE check on the tags in case someone added a 'null' in the collection.
Emergency rollback. None of us tested editors it seems. Can't use showView(*) on editors, whoops.
Created attachment 174887 [details] WorkbenchPage patch v3 Alright, let's not try to show editors as views...
(In reply to comment #15) > Created an attachment (id=174887) [details] > WorkbenchPage patch v3 Paul, please review this v3. :(
OK, this also makes sense. +1 Boris, is this behaviour OK? PW
yes, I'm fine with opening another editor instance.
Well, I hope we don't need to respin another patch.
Verified on Windows XP with I20100721-2056.
