Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1.Went to the context tab of a task that had every file under a largish project (several thousand) included in the context. 2.Right clicked the project in the elements section of the screen and clicked remove from context. More information: This caused the processor to max out at 100% for a few minutes. The elements section of the window was updating (flickering) several times a second while this was happening. + icons kept appearing then disappearing next to all the folders of the project that did not have any children each time the view flickered. I wonder if it is doing some check in the background to find if folders have any contents after removing each file from the context that could be left until the end when all files are removed from the context? I got this after experiencing bug: 202793
The problem is that the removal of each resource is processed independently. We will be able to improve on this by batching the removals.
Tentatively scheduling for Mylyn 2.2.
*** Bug 196120 has been marked as a duplicate of this bug. ***
Improved by a factor of 2 or more, but the underlying need for excessive refresh is not fixed (need to queue up delta of element deletions) and that change might have to wait for Mylyn 3.0 since it will break API. One thing we could do for now is queue up the refreshes themselves.
Created attachment 82594 [details] mylyn/context/zip
*** Bug 210433 has been marked as a duplicate of this bug. ***
On a large context this can cause a pretty serious performance/refresh problem.
Created attachment 84751 [details] patch I have attached a patch that addresses this problem. There is now and IInteractionContextListener2 that can be implemented and is batch notified of elements deleted. Also, I have made manipulateInterestForElement batch up the changes before notifying. This has much improved performance for views that refresh based on element changes. The only thing that I am unsure of is that the FocusedViewerManager now refreshes the entire tree when it recieves an elementsDeleted notification. I did this since to be smart for this case would require finding the topmost parent in the set of deleted elements. If you want me to look at doing it this way I can.
Created attachment 84752 [details] mylyn/context/zip
Created attachment 84761 [details] updated patch It turns out that I missed the context editor form page in my previous patch
Created attachment 84762 [details] mylyn/context/zip
It looks like I might have missed a couple more classes too. ContextWorkingSetManager and the ActiveSearchView anonymous class. Instead of me making another patch for these 2 more classes, can they just be updated before this is resolved?
Excellent! Patch applied, changes made, and note on merging IInteractionContextListener and IInteractionContextListener2 added to porting guide.
Shawn: fyi, in terms of testing, we have tests for deletion which should cover this. At some point we need better tests for viewer refresh + deletion, but covering this boils down to our having a performance test harness.
Reopening because editors won't auto clse when parents are removed from context.
I just tested this and was unable to reproduce this problem. Are there any steps to reproduce?
Sorry, I just realized that I had Manage Editors off in my test workspace. The only reproducible instance of this I am aware of is bug 212285, which means that if you remove a non-Java project from context, files within that project won't automatically close since they are not removed from context. Eugene: if you can reproduce with Java projects please post detailed steps after ensuring that your preference for managing editors is on.
I just reproduced it on last dev build. The sequence is something like this: - I have workspace with org.eclipse.mylyn.aspectj and org.eclipse.ui.workbench.texteditor plugins - create some task, activate it and make sure focus on active task is turned on in the Package Explorer view - open IAdaptable from org.eclipse.equinox.common plugin using Open Type (Ctrl-Shift-O) dialog - make sure that IAdaptable class does appear in the Package Explorer. This usually require some Alt-clicking magic on org.eclipse.mylyn.aspectj / Plugin Dependencies / org.eclipse.equinox.common (seem like another bug) - after that IAdaptable is shown two times in the Package Explorer - first is under org.eclipse.mylyn.aspectj and second - under org.eclipse.ui.workbench.texteditor (they both have org.eclipse.equinox.common as dependency) - now select org.eclipse.equinox.common jar entry and remove it from the task context. - after that IAdaptable node is not shown anywhere in the package explorer, but editor opened for IAdaptable is not closed. Also, second entry for org.eclipse.equinox.common is also shown in the Package Explorer view
Hey Eugene, I am unable to reproduce this problem. I am marking this as resolved as there was no behavior change from my testing. If you continue seeing this, please open a new bug.
