Community
Participate
Working Groups
Some teams have 1000's of top-level projects in CVS. When doing a "Refresh branches", we have to manually search for the right project among all the others. If the dialog used a FilteredTree instead, it would be a great productivity booster.
I agree that this would be helpful but there are some limitations in the sense that not all nodes in the folder hierarchy are known. So, for instance, if you were looking for a project that was not at the root level, filtering may not work (or, another way to look at it is to say that making it work is not trivial).
The "Refresh Branches" dialog doesn't show a tree structure. It looks like it's just a flat list projects.
You're right. I was thinking of a similar request we had for adding filtering to the Repositories view. Given that it is just a list, using the FilteredTree shouldn't be that hard if someone wanted to take a crack at it.
Created attachment 68118 [details] Dirty patch (need serious refactoring) This patch should not be contributed. It only shows the obstacle I have hit: FilteredTree has very poor support of SWT.CHECK style - it does not remember association between TableItem check state and the data underlying it. Results are visible when playing with filters and Select All (which should select all visible elements IMO). When clearing the filter, check states are not moved with data. There is no workaround for this, since the refresh Job is launched 200 ms after filter change and destroys manual changes. Any ideas?
I don't really have much to say at this point because I am focusing most of my effort on 3.3 issues. It seems to me that there would be three approaches to handling this: 1) Have the client (i.e. the Refresh Branches dialog) keep track of the check state 2) Have the FilteredTree track the check state 3) Subclasses FilteredTree and have the subclass manage the check state (e.g. CheckboxFilteredTree) I think the best approach is 3 but it may not be possible without modifications to FilteredTree. I don;t know anything about the implementation of FilteredTree but I can speculate that you would need callbacks from the tree when the items being displayed changed so that you could update the check state.
I'm not sure if the discussion is over. Anyway the only thing that we have so far is the dirty patch which I hope will become a clean patch during 3.5. Lowering the priority to the value appropriate for 'helpwanted' issues. Krzysztof?
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.
