Community
Participate
Working Groups
I20110127-2034. 1. open CH on foo 2. add bar via DnD 3. delete foo 4. refresh ==> foo is not coming back. However, deleting the last node (so that view is empty) and then refresh, brings back that node. ==> either never bring back a root or always bring them back.
See also bug 335275.
Discussed with Dani. A solution that avoids the inconsistencies with the last root and that brings us closer to the Search view behavior is this: - Adding new roots always adds them to the current history entry and makes sure they show up in the CH view (even if they have been removed before). - Removing a root only removes it from the view but does not touch history. - Refresh of the whole view shows all roots again
(In reply to comment #2) > - Removing a root only removes it from the view but does not touch history. Makes sense. But a user must still be able to add (ctrl+drag) back a removed root.
Consider the below scenario in CH view: -bar + foo -foo + bar Delete the child node #foo from CH view. After deletion the CH view: -bar -foo + bar Now refresh the CH view: -bar +foo The root node #foo is removed on refresh and the originally removed child node #foo is recovered, which looks wrong. After refresh the expected UI is: -bar + foo -foo + bar
Created attachment 229361 [details] Patch. With this patch, after a node is removed (either child or parent), on refresh of the view the removed nodes are re-populated in the view. Remove does not touch the view history. Adding a removed node again via drag and drop and then refresh will not show duplicate nodes. Updating the view header label, when node is removed and filters are applied will be handled as a separate bug.
Thanks Manju! Committed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8715274aefc5cc4622fa79612694ce83063f2fad
Verified in I20130522-2000.
