Community
Participate
Working Groups
In bug #234177 comment 1 John said: >In particular, >StructuredViewerProvisioningListener invokes a refresh of the view for each >repository discovery event, and since the Ganymede site has 62 references, it >causes 62 refreshes of the tree and the UI goes berserk. This actually happens on repository add events, but the symptom is correct. The viewer listener will refresh for every add. Some of my experiments in bug #229069 involved trying to ignore refreshes when I knew there was a pending refresh. Due to the async nature of the event handling, this approach didn't fix bug #229069 so I did not release any of those experiments. However, a similar approach to the first patch in bug #229069 should be adopted generically by the StructuredViewerProvisioningListener. Specifically, the implementation of asyncRefresh() could check a flag to see if a refresh was already pending, and if so, another one would not be queued up.
The other issue involved here is that the AvailableIUGroup currently expands added repositories and when batching, we probably shouldn't bother expanding.
>The other issue involved here is that the AvailableIUGroup currently expands >added repositories and when batching, we probably shouldn't bother expanding. That issue is now covered separately in bug #236485
attempts to solve this are happening in the api branch, should be able to close this once we're happy with a solution.
marking fixed (in the branch). The events themselves remain internal, but there is a way for clients to signal to ProvisioningUI that they want to batch a repository operation and then provide detail about what happened when it's done.
changing milestone to M5. The p2 api branch will be merged back into HEAD early in M5
verified on win7, I20100126-0100 (source inspection) and by virtue of related bugs being fixed/verified
