diff options
author | Thomas Wolf | 2018-07-24 21:19:12 +0000 |
---|---|---|
committer | Thomas Wolf | 2018-08-06 19:53:27 +0000 |
commit | 6ee58057c2dc1ab8498651e1ab91955289f7e981 (patch) | |
tree | a96324ec43af9989bd54840e7ddebe3d63e9f421 /org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/variables | |
parent | f83e6aeca768531f345f9092afd384bf763ff7ae (diff) | |
download | egit-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/src/org/eclipse/egit/ui/variables')
0 files changed, 0 insertions, 0 deletions