Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorThomas Wolf2018-07-24 21:19:12 +0000
committerThomas Wolf2018-08-06 19:53:27 +0000
commit6ee58057c2dc1ab8498651e1ab91955289f7e981 (patch)
treea96324ec43af9989bd54840e7ddebe3d63e9f421 /org.eclipse.egit.ui.test/.gitignore
parentf83e6aeca768531f345f9092afd384bf763ff7ae (diff)
downloadegit-6ee58057c2dc1ab8498651e1ab91955289f7e981.tar.gz
egit-6ee58057c2dc1ab8498651e1ab91955289f7e981.tar.xz
egit-6ee58057c2dc1ab8498651e1ab91955289f7e981.zip
Use an asynchronous lightweight decorator in the repositories view
In the previous implementation, the label provider produced styled labels that included the decorations. But label providers run in the UI thread, and expensive decorations like a branch state (N commits ahead, M behind) could thus lead to UI blocks. Newly, leverage Eclipse's built-in support. Use a lightweight decorator for RepositoryTreeNode and register it in plugin.xml. Separate out getting labels into a WorkbenchAdapter and adapt the GitAdapterFactory accordingly. (We already created a WorkbenchAdapter there, but first we always created a new one, and second, it always created a RepositoriesViewLabelProvider just to get the label text. That's terribly inefficient and the logic is completely backwards.) Also use ImageDescriptors instead of Images where possible. Factor out the handling of LabelProviderChangedEvent from GitLightweightDecorator into GitDecorator and re-use it in the new decorator for RepositoryTreeNodes. Make the RepositoriesViewLabelProvider a decorating label provider based on a WorkbenchLabelProvider, which uses the singleton RepositoryTreeNodeWorkbenchAdapter to get labels and images. Change the other uses of RepositoriesViewLabelProvider in dialogs to work with the new setup. Adapt git repositories view tests. These often use the label provider to determine expected node labels, and then try to find a node with a matching label. Decorations are now asynchronous, and thus the label returned from the label provider may or may not contain the decoration. Even with waiting for decoration jobs we may end up with the label being determined in the test and the one in the UI being different. The latter may or may not contain the decoration, which makes finding expected nodes a bit difficult. For now, use the TestUtil navigation methods, which just check for containment. This works well, but because some decorations include the repo directory path which in turn includes the test method name, some test methods and even some test repo names had to be changed to avoid false "duplicate nodes" failures. User-visible UI changes from all that: next to none. Three differences I noticed in the default theme on OS X: 1. Decorations all use the default decoration style (light brown), with the exception of the directory paths shown on repository nodes and on working tree nodes. Those are handled specially and use the qualifier style. 2. Decorations in the "File->Import...->Projects from Git->Existing git repositories" page now actually work. 3. Image decorations briefly flicker on a refresh because of the way asynchronous lightweight decorators work. The flickering is due to the repository view being wholly refreshed frequently. On such a refresh, the viewer tries to get a new decorated label, but the decoration isn't available yet. Once it is available, an event is fired, and the viewer updates the label again. For text labels, the new RepositoriesViewLabelProvider contains a work-around, but for images, that method won't work. The only image decorations (so far) are the check markers for the currently checked-out ref. Otherwise, I notice much faster Eclipse startup with the repositories view open and containing some repositories. Bug: 536814 Change-Id: Ifa8279dd6755c57696b8b64e96bc41a1f948aa59 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Diffstat (limited to 'org.eclipse.egit.ui.test/.gitignore')
0 files changed, 0 insertions, 0 deletions

Back to the top