Community
Participate
Working Groups
When having long list of versions/branches and number of module in the repository it is difficult to choose the right one. It will be very very useful to be able to specify a filter for version/branch names. It can be text entry field at the top of the layout similar to "Choose Type" dialog and should support patterns the same way as they supported by type/resource dialogs.
I have large project with hundreds of tags and branches and it is really insane to use current branch/version selection dialog. Any chance to get this feature implemented in 3.0.1 or 3.1 release? Thank you.
We are not planning any enhancements in 3.0.1, but will instead target 3.1.
In general it is difficult to use CVS Repositories view that have large number of projects. It would be nice to be able to have entry field at the top of this view to specify quick filter (like */proj*/**/*). Similar UI work quite well for Ctrl-O/Ctrl-T pop-ups in Java editor. Should I fill this as a separate bug report?
Filtering has been added to the tag selection dialogs. The repository view does have the ability to filter by working set but this could be improved. Also, there is no way to filter the tags shown in the repositories view
Thanks Michael. But what I'd really like to see is something similar to FireFox's Ctrl-F panel for quick filtering based on matching pattern. This kind of UI is very efficient for long lists. Mozilla's ThunderBird also has such quick filter for email panel and it is really convenient.
In essence, that is what we have added for filtering tags in tag selection dialogs. I agree that this would be handly in the repositories view as well. However, this may turn out to be a fair bit of work and is currently not scheduled to be addressed in 3.1. It is marked 3.1 because we would like to do it time permitting but we may not have the time.
Not for 3.1
*** Bug 83808 has been marked as a duplicate of this bug. ***
Michael, can you push for this functionality to be implemented on a SWT/JFace widget level? E.g. tree, list and table widgets could provide an infrastructure for an efficient filtering.
The problem is that the tree in the repo view is lazily populated. This makes a general solution (or even a specific one) complicated.
Isn't this lazy population is driven by widget events (e.g. "expand node")? If so, it should be possible for activated filter to simulate "expand node" events (perhaps we can have a setting on a model level that will indiacte if model is using lazy population).
Yes, that may be possible. My concern is that the performance would be unacceptable but I could be wrong. The only way to find out would be to prototype it. I don't have time to do it. Do you?
Aren't you cache it once it had been opened? Filter can show as much as it can find and continue scanning in the background. Anyway, there is number of places where model is getting data from a local source or not using lazy initialization. That is why it is wery important to prototype it on a widget level and unfortunately I have no experience with low-level SWT/JFace. Can you suggest some person who may have a better idea about this? Or perhaps we should create a separate feature request for SWT/JFace and make this bug dependent on that new request. What do you think?
I think that SWT is too low level for this. It's possible an argument could be made to put it into JFace but the UI team is already overworked so you won't get any help there. If this were to more forward, the best approach would be to prototype such a filter in the repository view and then, once it was successful, to see if the solution was generalizable to TreeViewer. Unfortunately, the repository view is not in good shape for these type of changes (i.e. yes, it would make sense if the remote model were cached somewhere but, at the present time it is not). My feeling is that it would take a fair amout of effort to add this the the repository view. Given that most developers can work without the repository view, it is not a high priority. So, the bottom line is that if you really want to see this happen, you may want to learn more about SWT/JFace and have a look at the RepositoryView code.
I should also add that you are free to post questions about the feasiblity of a generic tree filter to the eclipse-platform newsgroup or the eclipse-ui-dev mailing list. My feeling is that you probably wouldn't get much of a response but I may just be a cynic;-) It can't hurt to try.
Speaking about prototyping, it would make more sense to base prototype on Java Package Explorer view. At teast everybody is using that one and it is all local...
Makes sense to me. In that case, it may be worthwhile to ask for opinions on the eclipse.tools.jdt newsgroup of the platform-jdt-ui-dev mailing list.
I agree with the reasons for prototyping on the package explorer, but from the usability point of view, its not as useful, I didn't find it really needed there (working sets are doing a good job in that domain). this kind of filtering is needed most where there are potenitaly many items, which are hard to categorize before hand. (java types and repository view are good cases). as for the issue of local vs remote items: what I had in mind in Bug 83808 was to filter just the first level of the cvs repository (module names). this is easier in the sense the entire list is fetched at once.
Omry, the filter I was talking about would allow to specify any criteria, so filtering by first layer only is just a partial case (e.g. you can specify jakarta-*/**/*Bean.java or jakarta-*/**). This basically mean that you always have handy replacement for Ctrl-Shift-O/Ctrl-Shift-R dialog. If this quick filter would keep history of filters it will be a killer feature that is much more useful then worksets. BTW, personally I found worksets in package explorer difficult to use. It has been improved recently, but still far away from intuitive. Probably it is only because I usually have over 50 projects in my workspace.
Eugene, I realized that what I proposed is different from what you proposed, and can probably be implemented as a special case in what you propose : node pass filter if (node parent is cvsroot node and node name match pattern) or (node parent is not cvsroot)) but at least for the repository view, I think thats all really needed. of course, any solution which allow it is good. I just noted that implementing something which does the work exactly, may be much simpler than trying to come up with a working solution for the general problem. as they say: its better to have one bird in your hand than ten on the tree.
Omry, sure it will be easier to implement something for a single view. I just trying to make a point that it will be more efficient to implement something generic, so all view will get it at once. From other hand I agree with Michael that it should be prototyped somehow and then generalized. Actually there is some activity happening on this direction. You may noticed quick filter in all properties dialogs. Unfortunately it does not support masks (eg **/name) and UI could look better (I believe that the way how it look in Ctrl-O and Ctrl-T popups is more elegant then have separate entryfield), but besides that it is trying to implement very similar idea.
*** Bug 76065 has been marked as a duplicate of this bug. ***
*** Bug 110705 has been marked as a duplicate of this bug. ***
There is currently no plan to address this item.
well, I guess the 10 birds on the tree won.
I'm not really sure what you mean there. Moving this to LATER says that, while we think this would be a good feature, we do not have the manpower to address it. We would be happy to accept a patch if someone felt strongly enough about it to provide one.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
