Bugzilla – Full Text Bug Listing
| Summary: | When navigating to a parent graph, the viewport and layout are not restored. | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Matthias Wienand <matthias.wienand> |
| Component: | GEF Zest | Assignee: | Alexander Nyßen <nyssen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | nyssen |
| Version: | unspecified | ||
| Target Milestone: | 3.10.1 (Mars SR1) RC1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Matthias Wienand
I added a ViewportStackModel to keep track of scroll positions, zoom levels, and already layed out graphs, so that these can be restored when navigating back to a parent graph. The changes only extend the current API. The code is published on the master branch, therefore, I resolve this ticket as fixed for 3.10.0RC1. I performed some tests on my machine and cannot confirm that this is fixed properly. While the layout is preserved, the zoom-level at which we step into the nested graph seems to be higher than the one we are in when leaving it again. We should fix that also. Resetting target milestone, as not fixed in 3.10.0 RC1. Currently, the ViewportStackModel maintains a list of graphs for which the next layout pass is to be skipped in order to preserve the layout when navigating back to a previously already layed out graph. This functionality should be moved into a separate model, because it is unrelated to the viewport. The problem is related to pinch/spread. The cause is that when using pinch/spread to zoom out, the spread gesture is not completed yet when the OpenParentGraphOnZoomBehavior restores the viewport, the FXChangeViewportsPolicy is still in an active transaction (init() was called, commit() will only be called when the spread gesture completes). However, FXChangeViewportsPolicy does not recognize that the ViewportModel was changed after init() was called and will apply the relative zoom to the initial viewport (before viewport was restored by OpenParentGraphOnZoomBehavior). We can resole this by registering a listener to the ViewportModel within FXChangeViewportsModel and reacting to changes of the viewport. However, investigation will still be needed w.r.t. to proper fundability in these cases. It may be a better idea to turn the OpenParentGraphOnZoomBehavior and the OpenNestedGraphOnZoomBehavior into policies, so they could synchronize their behavior with the respective zoom policies. Maybe FXChangeViewportPolicy can be extended in Zest to perform the viewport push/pop operations. It could then perform the synchronization internally. I have re-investigated this. I think, at first, we should enhance the ViewportModel with the push/pop functionality currently offered in the ViewportStackModel. Also the FXChangeViewportPolicy can offer respective functionality for pushing/popping the viewport state. Thereby, synchronization with the current zoom operation can be performed within FXChangeViewportPolicy. I replaced the push/pop mechanism with a mechanism that stores a viewport state for each graph from which navigation was started (so that viewport can be restored when navigating back). Renamed ViewportStackModel into NavigationModel and introduced a NavigationPolicy that is now used by OpenParentGraphOnDoubleClick and OpenNestedGraphOnDoubleClick policies, so the navigation can be properly undone as well. The OpenNestedGraphBehavior and OpenParentGraphBehavior behaviors also make use of the NavigationPolicy now, but the do only apply the respective changes without properly initializing and committing the policy. We will have to replace this. Also, we will have to replace that up to now, the NavigationPolicy directly manipulates the FXChangeViewportOperation of the FXChangeViewportPolicy to apply the viewport changes. I opened bug #475190 to keep track of the remaining refactorings and resolve this as fixed in 3.10.1 RC1. |