Community
Participate
Working Groups
In the current RSE SystemView, when a remote folder is refreshed: - all children below that folder are immediately removed - a RefreshJob is started ("pending") - children of the refreshed item are queried but only 1 level deep, so - existing "expanded" state of subfolders is lost and - existing selection of subfolders is lost. This behavior is not acceptable for some subsystem implementations. "Flickering" of the tree must especially be avoided when periodic refreshes are scheduled, see bug 150954 and bug 161431. Some requirements for an improved Refresh are: - While the refresh is still ongoing, existing items must be still usable - There must be an option to do a "deep refresh", i.e. refresh all visible items below the selected node instead of collapsing to 1 level - When the new data is available for the refresh, update must be non-intrusive: - Items that are not changed must not be modified - Items with change of properties only but no change of structure need to retain the same node in the SWT tree (Tree.update()) - User selection below refreshed items must be maintained (at least for items that are not modified by the refresh) - "expanded" state of subfolders must be maintained (at least when the corresponding folder does not change due to the refresh). Since optimized implementation for such refresh capabilities may vary for various subsystems or models, we propose making the Refresh policy pluggable. In terms of API, the Refresh Policy will need to closely interact with the SystemView: since it decides for what Items the TreeViewer needs to do it will need to know about the mapping from remote element to Tree Item and perform the StructuredViewer.refresh() and StructuredViewer.update() methods correctly.
This is a must-have for our product. Assigning M6 since it involves API change.
Shooting for right after M6
It turns out that most problems of refresh (losing selection and expand state) are due to the SystemDeferredTreeContentManager, which schedules jobs for getting remote data from slow systems. Bug #150954 comment 13 has a suggestion how this could perhaps be fixed, but the solution does not seem elegant. For the longer term future, we should rather look at what the Platform Debug and DSDP-DD teams have been working on in order to support custom refresh policies. Until this is done, the recommended workaround for clients is to do their own asynchronous updates, and indicate this with supportsDeferredQueries==false in their SubsystemConfiguration as well as their ISystemViewElementAdapter. They can further optimize Refreshes by not implementing IRemoteElementAdapter in their ISystemViewElementAdapter. Bug #150954 comment 12 has a description of an algorithm that clients can use. An important point is the separation of "Refresh Viewer Only" vs. "Refresh getting new data" that can be accomplished by a local subclass of SystemResourceChangedEvent. Important bug fixes for making this work have been done in bug #186991, and bug #181145. Since these were the most problematic road blockers, I'm moving this to P3 / Future for now.
