Community
Participate
Working Groups
When navigating through the changes (incoming/outgoing/both) in the Synchronize view of the CVS perspective, it's sometimes nice to see all the changes. You can expand a single item by right-clicking on it and selecting 'expand all', but it only expands the children of the item that you have selected. If you've got multiple projects, you have to 'expand all' all of them. There's a 'collapse all' button in the view toolbar -- having an 'expand all' button there would really be great.
Please don't add it to the toolbar. It is already busy. But both collapse and expand actions should be available on the view menu (Ctrl-F10). BTW, Alex, you can call expand from the view popup menu - Shift-F10, X
You cannot call it from the pop up menu in the way you describe; it has exactly the same behaviour as right-clicking on an item and doing 'expand all'. If you have nothing selected, or there are multiple items, you have to 'expand all' individually. The collapse all does not have that behaviour; it will collapse all of them, regardless of how many there are present or whether there is a selection or not. Other views -- e.g. the search view -- have both expand and collapse as menu buttons on them and have the same behaviour as the one I've described/proposed here. I don't see why the synchronize view should be any different in this regard.
I think it is safe for the Search view to provide an expand all since it's model is pre-built and search results tend to be small (<1000). While it is true that the number of Sync view entries tend to be small, the model is not pre-built so there is a bit more work that happens when items are expanded. So really, I have two concerns here. The first is what Eugene mentioned. The toolbar is already full. The second is that, if there are a large number of entires in the Sync view (i.e. in the thousands) and the user executed an expand all, the expansion could take a considerable time and would block the UI thread. Given that the later case, is rare, I don;t consider it as important as the first point. I don't have the time towork on this in 3.3. However, I would be willing to accept a contribution if someone wanted to provide one. As Eugene pointed out, it probably shouldn't be a toolbar item but could be a context menu item (i.e. make expand all work for no selection) and work when Shift-F10, X is used.
Michael, it can expand to N level down to limit the model scanning. Also, I think that view menu is a better place for such action, since it is not context specific. So, expand from popup menu would work for selected items as Alex pointed out.
Whilst I agree that a lot of differences are likely to block the thread for a short amount of time, if there are hundereds of projects it will take a lot longer to expand them all :-) In any case, it's mostly useful for when there are small change sets. Limiting it to a maximum level of N would hardly meet the definition of 'Expand All' :-)
I know that old habits die hard, but there is "Next Difference" and "Previous Difference" on Sync view toolbar. You can actually use those and view will expand whatever is required when moving to the next difference. Personally I am not using those buttons, neither "Update all incoming changes". So, in total, I have 4 useless buttons on Sync view toolbar... Another space eater is the "Incoming/Outgoing/etc" mode set, it is a mystery to me why those aren't drop down. :-)
Yeah, the mode is also shown on the view menu, too. Perhaps a drop down would make more sense. Alternatively, you could have boolean menu items to toggle the 'expand/contract', 'synchronize mode' buttons on/off, so everyone could have what they want in the toolbar :-) Of course, you can always make the 'synchronize' view a bit wider to get it all displayed, too ...
You can't make it wider the the screen... Anyways, stop talking and contribute some patches already! :-)
It's on my todo list ...
Created attachment 99100 [details] Patch resolving the issue The provided patch resolves the described issue. It places the "Expand All" button neat the "Collapse All" one. The added button expants the whole tree. Also the ExpandAllAction from synch view drop down is improved - if the selection is empty, it expands the whole tree, and when not, only the selection, as it was earlier. To get the thing work fine you should also add appropriate expandall.gif files to the following directories: /org.eclipse.team.ui/icons/full/dlcl16/ - disabled icon /org.eclipse.team.ui/icons/full/dlcl16/ - enabled icon I don not add the gifs to the patch, cause as far as I know the patches work badly with binary files. They can be found in other eclipse plug-ins. Hope the patch is well and will be applied soon, cause our users do want to see this buttons together:). The patch is done to the today's head version of the module. The screenshot of the result to follow;).
Created attachment 99102 [details] The screenshot of the result of applying the patch.
Szymon Brandys asked: Why can't you just contribute the action to the sync view like Eclipse does? The toolbar can be extended with custom actions using SubscriberParticipant class and org.eclipse.team.ui.synchronizeParticipants ext. point. Reply: There are two reasons: - It's possible to add actions to the end of the toolbar - that's not the expected order for this particular action - Our patch can help other Team Providers to use "expand all" action instead of implementing own action
(In reply to comment #12) > Reply: > > There are two reasons: > - It's possible to add actions to the end of the toolbar - that's not the > expected order for this particular action So maybe contributors should be able to modify the order of items in the toolbar? > - Our patch can help other Team Providers to use "expand all" action instead of > implementing own action I agree, but some can complaint. What we can do is to release it at the beginning of 3.5 and see what people will say.
> I agree, but some can complaint. Example, please.
(In reply to comment #14) > > I agree, but some can complaint. > Example, please. > See Michael concerns from comment 3. For me having only '-' in the Sync view is consistent with Package Explorer and Project Explorer. Expand All is available in the context menu and you can still add the '+', however the order of items in the tool bar is not satisfactory. This should be changes as I suggested earlier. However the discussion is open. I would like to give people a chance to comment on it. Maybe Tomasz will put in his two cents' worth?
So, once again. Let's look at the situation calmly:). How did I came to THIS bug? The history of my immigration: 1. We got a https://bugs.eclipse.org/bugs/show_bug.cgi?id=230868 2. I've tried Subclipse and found, that they incounter the same problem. 3. I found the same request in Team Services bugs. The bug contains "helpwanted", so I decided to help, and now it turns out that really no help is needed. That's the case.
(In reply to comment #16) > So, once again. > Let's look at the situation calmly:). Sure, I'm always calm :) > > How did I came to THIS bug? > The history of my immigration: > 1. We got a https://bugs.eclipse.org/bugs/show_bug.cgi?id=230868 > 2. I've tried Subclipse and found, that they incounter the same problem. > 3. I found the same request in Team Services bugs. > The bug contains "helpwanted", so I decided to help, and now it turns out that > really no help is needed. That's the case. We want to fix the bug and your help is appreciated. My doubt is not about fixing the bug, but about how to do it (see comment 13) We are discussing possible solutions. The easiest way is to add just another item to the toolbar. An interesting idea would be to have configurable toolbar though. IMHO we should continue the discussion about the sync view and how it should be rearranged. The quick fix will be released early during 3.5.
(In reply to comment #13) > > - It's possible to add actions to the end of the toolbar - that's not the > > expected order for this particular action > > So maybe contributors should be able to modify the order of items in the > toolbar? I think that's the point. Guys, imho to move the discussion forward we would have to provide a way the client could decide how to organize his contributed actions. Igor, Alexei are you able to suggest what changes in our API would make you happy, ie able to put the action where you need it? This would change the nature of the bug as it will be more about how to contribute the action by the client (you guys) instead of a request for the action, but I assume this would make both sides satisfied. We could even open a separate bug for the new "organize-action" API and fix it, and leave this one open. How does it sound?
Created attachment 127827 [details] mylyn/context/zip
If you're talking about new API, which is imo the best solution, the train has already left the station. Given the fact that there has been no feedback recently, I'm postponing the bug to early 3.6 when I will propose new API, and when interested adopters will have enough time to sent their comments. The initial idea is to add options to: * show/hide sections (see comment 7 from Alex) * add a new action at the beginning/end of a section (comment 12 from Igor) * change order of items/sections in the toolbar (see comment 13 from Szymon)
The new API is likely to help fixing bug 71552 as well.
Created attachment 141193 [details] Patch v02 Keeping in mind the "less is more" motto I'm submitting a patch that simply moves the "Collapse All" button to the left (before Next/Prev difference buttons). This way when adding the "Expand All" button with appendToGroup[1] you will get the buttons in the correct order placed in the same action group. Alexei, please correct me if I missed something but briefly looking at the Subversive source code it appears that changing ISynchronizePageConfiguration.MODE_GROUP to ISynchronizePageConfiguration.NAVIGATE_GROUP in UpdateModelActionGroup[2] should do the job. Please let me know what do you think about it. If you're fine with the fix I will be happy to release it and finally close this bug. [1] org.eclipse.team.ui.synchronize.SynchronizePageActionGroup.appendToGroup(String, String, IAction) [2] org.eclipse.team.svn.ui.synchronize.UpdateModelActionGroup.configureActions(ISynchronizePageConfiguration) line 117 in rev 20532
*** Bug 289865 has been marked as a duplicate of this bug. ***
Is any of Subversive/Polarion guys interested in having this fixed? If so please provide your opinion about the patch from comment 22.
(In reply to comment #24) > Is any of Subversive/Polarion guys interested in having this fixed? If so > please provide your opinion about the patch from comment 22. Tomasz, I checked your patch and it works either in model-aware and not-model-aware Sync views. It's a simple solution but it's applicable for us as it resolves our problem. What are you thoughts about other issues discussed in this bug: providing new API, adding Expand All action in Team component in order it to be accessible for other Team developers (of course, I read discussion and understand all pros and cons, I 'm just interested what you're going to do).
(In reply to comment #25) > Tomasz, I checked your patch and it works either in model-aware and > not-model-aware Sync views. It's a simple solution but it's applicable for us > as it resolves our problem. I'm happy to hear that. > What are you thoughts about other issues discussed in this bug: providing new > API, adding Expand All action in Team component in order it to be accessible > for other Team developers (of course, I read discussion and understand all pros > and cons, I 'm just interested what you're going to do). Well, my opinion hasn't changed much: - I'm still not convinced (which doesn't mean I'm against it) that we should add 'Expand All' for the same reasons as mentioned in comment 3 and comment 15. However if we decide to fix bug 291016, we will no longer be able to complain that 'the toolbar is full'. So I guess bug 291016 could be considered as blocking Alexei's patch (attachment 99100 [details]) from releasing. - At the same time I'm aware the current situation may not be comfortable for adopters thus prepared attachment 141193 [details]. I think we could create a separate bug for the contributed 'Expand All' button placement issue. This way we could fixed that bug (which would solve your problem) and continue the discussion about adding the action on this bug. - I still think an API for organizing actions in sync view's toolbar would be nice to have (see comment 20)(an option to do it declaratively would be even better), but I'm afraid we don't have the manpower to address it at this time. BTW, this could be a separate bug as well.
(In reply to comment #26) > I think we could create a separate > bug for the contributed 'Expand All' button placement issue. It's bug 301114, targeted for 3.6M6. I'm removing the target milestone on this bug to better match the reality.
Can this please be re-evaluated? I don't want to even think about how much time I've wasted double-clicking each individual project instead of being able to click a little + icon. As far as I'm concerned this is the biggest missing feature in Eclipse.
(In reply to comment #28) > I don't want to even think about how much > time I've wasted double-clicking each individual project instead of being able > to click a little + icon. Thomas are you using SVN? If so, the patch from comment 22 should work fine for you as long as guys from Subversive consume it. Is that your case?
Nope, using CVS. Can I still use the patch?
(In reply to comment #30) > Nope, using CVS. Can I still use the patch? I can see that this patch was already been applied in bug 301114 and it's available in builds >N20100131-2000.
(In reply to comment #31) > (In reply to comment #30) > > Nope, using CVS. Can I still use the patch? > I can see that this patch was already been applied in bug 301114 and it's > available in builds >N20100131-2000. I have build 20120216-1857, and I don't see it. As I understand it, the patch from comment 22 only moves the '-' icon, and does not add a '+' icon.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
