-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reintegrate Zest 2.x fork into master #476
Conversation
Because the layout algorithm is executed asynchronously, it may happen that the layout is performed AFTER the graph has been disposed. Explicitly check the state of the graph to avoid this issue. This issue can easily be reproduced by opening and closing one of the snippets.
The class is referencing old Zest 1.0 methods for the sake of backwards compatibility. Given that those methods should no longer be used, they therefore produce a corresponding API warning. Because usage is intentional with no Zest 2.0 counterpart, we simply suppress those warnings.
The constructors where one could pass the data object has been marked for removal as part of the Zest 2.0 migration, with the suggestion to call setData() afterwards. However, this might not be possible for e.g. the CGraphNode, where the data object is returned by a call to createFigureForModel(), which then leads to an exception if this field hasn't been initialized yet. To remedy this situation, the constructors expecting a raw object as data remain deprecated and instead a new constructor has been created, where this object has to be of type IFigure.
This primarily cleans up the mapping of the LayoutContext to its sub graph in the DefaultSubgraphFactory and PrunedSuccessorsSubgraphFactory. In addition, some minor cleanup has been done when dealing with the node layouts, as well as on the refreshConnectionsVisibility() method.
Classes such as the NodeSearchDialog use translatable strings while other classes which use them as internal values simply suppress the warning.
The IContainer2 interface expects the GraphContainer and Graph class to return the package-private InternalLayoutContext when calling getLayoutContext(). This doesn't work if this interface is used outside the Zest package (e.g. in our tests) and prevents its from being implemented by clients. Instead, we return the public LayoutContext interface, with a via to access the package-private instance by calling internalGetLayoutContext(). Where necessary, the layout context is cast to its internal type, when its not clear whether the parent container is a Graph or a GraphContainer. Because of this, the getLayoutContext() have been made final.
The HorizontalTreeLayoutAlgorithm is already implemented by the base TreeLayoutAlgorithm class by using LEFT_RIGHT and the Horizontal-/VerticalLayoutAlgorithm is implemented by the BoxLayoutAlgorith with either SWT.HORIZONTAL or SWT.VERTICAL
The RotateGestureListener assumes that it is only possible to select nodes (and containers) inside a Zest graph, but not connections. Trying to do so causes a ClassCastException. To avoid this problem, we now explicitly check the currently selected items and only perform the rotation if all of them are nodes.
Clients should not implement the LayoutAlgorithm interface directly as we may want to add new methods in the future (similar to the Zest 1.0 case). Instead, they should implement the AbstractLayoutAlgorithm class.
@azoitl I've rebased the branch for a final time and from my perspective, we're good to go. Is there anything still open or can I finally press this big green button? |
291de6c
to
867bd77
Compare
This change has been delayed until the very end to avoid accidentally breaking the Zest 1.x legacy mode.
dbb0125
to
fb6711c
Compare
This is strange. Appart from the merge conflict I would say we should merge it. |
I have no clue what GitHub was on about, but I suppose the merge has worked now... |
We don't have to understand everything ;-) |
No description provided.