Community
Participate
Working Groups
I find myself using Rempve from view alot now that I have Eclipse as source in my workspace. It is a bit tedious to remove the same entries every time I restate Eclipse. I would propose the following adjustments to remove from view. 1) When an item is removed, remember that it is removed accross restarts 2) When the parent of removed items is refreshed, prompt if there are removed items to give the user the option to show them again. 3) If there is ever a state change on a removed item, show it. In some cases, step 3 may be undesirable as well, perhaps the user could be prompted in that case as well (although this is trickier due to the background refreshing).
I also noticed that the Remove from view action shows a progress dialog which doies not give the blocking job information. I did a remove from view at the same time a synchronize was happening and an old-style progress dialog was shown. Cancel was enabled but there was no progress occurring (I assume it was because the remove was b,ocked by the sync).
Not for 3.1
See also bug 147421 for a related feature.
We do not have the manpower to address this in 3.3.
*** Bug 177739 has been marked as a duplicate of this bug. ***
For 3.3 would it be possible to just add a 'Show Remove Items' somewhere?
We'll investigate adding a "Restore Removed Items" for M7.
Dani, am I right to assume that we would need to do this for both the old and new sync?
I don't care about the new one ;-)
Michael, could you give some clues where to start?
There are two places you need to change (because there are two different styles of Synchronize as outlined in this URL): http://wiki.eclipse.org/index.php/CVS_FAQ#Synchronizing_has_some_regressions_in_Eclipse_3.2._Why.3F For the old sync, look in the org.eclipse.team.internal.ui.synchronize.actions.SubscriberActionContribution class. That is where the RemoveFromViewAction is added. For the model-based sync, look in the org.eclipse.team.internal.ui.synchronize.actions.RefreshActionContribution class. That is where the RemoveFromViewAction is added. In both places, we should add an action to the view menu to restore any removed items. Have a look at the SynchronizePageActionGroup#appendToGroup(String, String, IAction) method to see how to add an action to the view menu. Of course, once you have the action added, you will need to restore the removed items. It will be different for both cases but the one similar trait is that neither keep track of the items that have been removed so you will need to reset them so that all items are readded. For the old sync, have a look at the org.eclipse.team.internal.ui.synchronize.actions.RemoveFromViewAction. The collector that the item was removed from has a reset method so you should get the right behavior by calling that method. The model-based sync may be a bit more difficult. For the time being, start to work on the old sync (since that's what will make Dani happy ;-) and, once we have all that in place, we can figure out a way to refresh the model-based sync.
Created attachment 62778 [details] Draft Is this good direction?
The patch is a good start. Here are some comments: 1) The action should be in the View menu and not the context menu. If it is in the context menu and I remove the last item, I can never get it back. To put it in the view menu, you should call SynchronizePageActionGroup#appendToGroup(ISynchronizePageConfiguration.P_VIEW_MENU, ISynchronizePageConfiguration.SYNCHRONIZE_GROUP, restoreRemovedItemsAction) from the initialize method of the SubscriberActionContribution. 2) Adding methods to a general class like SyncInfoSet is not really something we want to do. When the action is executed, just call collector.reset().
Created attachment 62911 [details] Draft 2nd I have created action, but I am afraid it is in other place (suggested solution did not worked for me). Maybe it is good idea to name it "Reset view"? Because this what actually this action does?
The suggested solution didn't work because the SubscriberActionContribution#fillContextMenu didn't call super. I added that and modified the code appropriately. I want to keep the menu item name as "Restore Removed Item" so the user knows when they would want to pick the item (i.e. "Reset" doesn't necessarily imply that removed items will be restored). I also removed the collection.run that wrapped the reset since a run is performed in the reset itself. I have released the patch to HEAD. Now for the model-based sync, you should add the menu in a similar way (i.e. add the menu where the remove action is added). As I mentioned, this case will be a bit harder. We may need to localize the fix to the case where we are using a SubscriberMergeContext. When the SubscriberMergeContext is used, you can get at the internal handler using the getAdapter method and then issue an INITIALIZE event to the handler. Take a look at the classes involved to get familiar with them and let me know if you have any questions.
Created attachment 64002 [details] Changes made in PrepareForReplaceVisitor I have no idea how to put errors to the CVS console...
Comment on attachment 64002 [details] Changes made in PrepareForReplaceVisitor The last patch should not go here, sorry
The mnemonic is missing (I20070418-1012), otherwise it works just fine - thanks!
Created attachment 64411 [details] Model based Restore removed items
Patch released (and mnemonic added).
Verified in I20070501-0010
