Community
Participate
Working Groups
Build: 3.4 p2 M2 This came up during discussion in Equinox summit... In the end-user UI, the list of "Available Features" and "Installed Features" can grow quite large (think of Ganymede release train, for example). It would be nice to have a filter box, like the preference dialog, to filter the contents of the feature lists
This would be helpful. We are also looking at categorizing IU's in a repo, so one would expect this feature list to evolve into a tree with filtering capability.
I investigated this briefly, and I think it's complex enough that it should be deferred. The main issue is that the tree content is populated using deferred content adapters, and the existing filtering mechanism does synchronous expansion/filtering. The net result is that the filter in its current form forces expansion of the entire tree immediately followed by filtering it. So the filter works on the temporary content of the tree ("Pending..."). There would have to be a mechanism of delaying the filter job until all of the deferred content jobs complete, which require a bit more knowledge of the inner workings of both the deferred content manager and the filtering mechanism. I'm also not sure I like the look of the filter itself in the dialog's current layout and the dialog would need to be reworked a bit. There are bigger issues to worry about right now...
investigate for M5
Fixed in HEAD >20080407. I spent far too long trying different ways to synchronize the operation of the filter job with the deferred content job, but the bottom line is that the filtered tree support relies on viewer filters to do the filtering, and for filter changes to take effect, the viewer has to be refreshed during the filter job. In cases where a node has never been expanded, this would cause a deferred fetch and a filter on the "Pending..." item, with no reliable way to know when the fetch is complete and a "refilter" should occur. I considered continually rescheduling the filter job while populating the viewer to keep the UI active while deferred fetching takes place, but the fetch jobs are private to the DeferredTreeContentManager. So there was not a reliable way of knowing when the filter job could start doing its work. Another approach would be to load repos in the background whenever the UI is launched and disabling filter text until they are loaded. However this carries a performance penalty regardless of whether the user ever filters or not. What I ended up doing was switching the tree's content provider to a synchronous mode the first time that filtering is requested. This can potentially cause a long delay in the UI thread if there are many repos that have not been loaded yet and the user types in the filter text, but the deferred content support doesn't have hooks for letting us pause a fetch job to run the event loop while fetching. It's time to move on, so I've opened bug #226052 to track this problem. If we see a lot of accidental typing into the filter text and annoying pauses, then I think we should consider background loading the repos all the time and only enabling the filter text when they are loaded.
