Community
Participate
Working Groups
The GEF4 Zest.FX plugin for graph visualization does not yet provide the same functionality as the GEF4 Zest.Core plugin. In order to get rid of GEF 3.x dependencies in GEF4 (Zest.Core uses Draw2d), the missing functionality has to be implemented. Missing visualization features: * Subgraph rendering * Nested graph rendering * Curved connections * Configurable colors * Displaying images * Animated transitions The current status of the GEF4 Zest.FX plugin and currently missing features should be registered on this bug. Therefore, if you have other missing features in mind, mention them in a comment, please.
I would extend the configurable colors feature to configurable formatting based on our existing implementation: * Configurable background/foreground colors * Border formatting for nodes * Full custom formatting (in case of the Draw2D API an IFigure could have been provided) Additional (minor) features: * Hover description * Fisheye-style zooming (this is not something I specifically require - I never use it in real applications :) )
(In reply to Zoltan Ujhelyi from comment #1) > I would extend the configurable colors feature to configurable formatting > based on our existing implementation: > * Configurable background/foreground colors > * Border formatting for nodes > * Full custom formatting (in case of the Draw2D API an IFigure could have > been provided) > > Additional (minor) features: > * Hover description > * Fisheye-style zooming (this is not something I specifically require - I > never use it in real applications :) ) I have forgotten to add to my previous comment that considering the CSS-based theming of JavaFX maybe we should aim for something similar here, instead of creating something entirely custom.
Thank you for the additions! To be able to properly use JavaFX CSS, I think we should try to use JavaFX Controls for the visualization, because for those, more CSS attributes are applicable (cf. [1]). Background, foreground, and border can be formatted using JavaFX CSS. So we get those for free when we load a style sheet. However, I am not yet sure about how to configure individual nodes/edges. Should the information be provided by the data model, i.e. using GEF4 Graph attributes? [1] http://docs.oracle.com/cd/E17802_01/javafx/javafx/1.3/docs/api/javafx.scene/doc-files/cssref.html#indexedcell
(In reply to Matthias Wienand from comment #3) In the old Zest, formatting information was provided by the Label Provider; however, it makes also sense to have some id/class attributes in the GEF4 Graph model. These attributes can also be set using a Label Provider-style interface, so I guess, it would be better in the graph model. > [1] > http://docs.oracle.com/cd/E17802_01/javafx/javafx/1.3/docs/api/javafx.scene/ > doc-files/cssref.html#indexedcell Are you sure this is current documentation?. If I recall correctly, JavaFX 1.3 refers to the first iterations of JavaFX, that works very different to the one available in Java 7/8...
Ok, I will start with integrating CSS then: loading a style sheet and evaluating id/class attributes of the data model. > Are you sure this is current documentation?. If I recall correctly, JavaFX 1.3 > refers to the first iterations of JavaFX, that works very different to the one > available in Java 7/8... Sorry for the wrong link, the current (JavaFX 8) documentation is at: http://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html However, there are still many more CSS attributes available for JavaFX Control in comparison to JavaFX Shape.
Created attachment 244798 [details] CSS styling example (July 3, 2014) I implemented foreground, background, border, and text styling and evaluation of the graph attributes "class" and "id". The styling is currently specified in a "styles.css" file. Although I am not yet using JavaFX Controls for the visualization (and thus cannot use their CSS attributes) you can get quite different looks with this basic setup. I added a snapshot of the Zest.FX example with CSS styling applied, so you can have a look without having to launch the viewer.
(In reply to Matthias Wienand from comment #6) > Created attachment 244798 [details] > CSS styling example (July 3, 2014) > > I implemented foreground, background, border, and text styling and > evaluation of the graph attributes "class" and "id". The styling is > currently specified in a "styles.css" file. > > Although I am not yet using JavaFX Controls for the visualization (and thus > cannot use their CSS attributes) you can get quite different looks with this > basic setup. I added a snapshot of the Zest.FX example with CSS styling > applied, so you can have a look without having to launch the viewer. The solution looks nice, thanks.
Created attachment 247938 [details] Hover description for node example
Features implemented since last update: - full custom formatting (by replacing the ContentPartFactory and creating your own NodeContentPart) - displaying images ('image' attribute, URL) - hover description ('tooltip' attribute, text) - displaying pruned neighbors (see #441202 for details) Still missing visualization features: - nested graph rendering (planned after the GEF4 Graph changes) - hover handles for prune/expand node (on the run, see #441202 for details) - animated transitions - curved connections Moreover, the appearance of a node with image and text has to be improved. Currently, the user cannot easily change the text alignment, for example.
(In reply to Matthias Wienand from comment #9) > Features implemented since last update: > - full custom formatting (by replacing the ContentPartFactory and creating > your own NodeContentPart) > - displaying images ('image' attribute, URL) > - hover description ('tooltip' attribute, text) > - displaying pruned neighbors (see #441202 for details) > > Still missing visualization features: > - nested graph rendering (planned after the GEF4 Graph changes) > - hover handles for prune/expand node (on the run, see #441202 for details) > - animated transitions > - curved connections > > Moreover, the appearance of a node with image and text has to be improved. > Currently, the user cannot easily change the text alignment, for example. What has to be added as well is rotation-support, which was covered by Zest.Core
As hover handles for pruning/unpruning of nodes have been added as part of bug #441202, what remains to be done here (before org.eclipse.gef4.zest.core can be removed) is the following: - nested graph rendering - animated transitions - curved connections - rotation support
Add dependency to bug #445849 which covers support for rotating elements within MVC and MVC.FX.
Since the last status update, two features have been implemented: - Nested graph rendering: For every rendered Graph, there exists one LayoutContext in the LayoutModel. Per default, nested graphs are only rendered when a certain zoom level is reached, and when zooming even further in, the contents of the viewer are exchanged with the nested graph. - Rotation support: Nodes can be rotated by dragging one of their selection handles while pressing <Control>, and the rotation is considered during layout. So what still remains is: - Curved connections: These are already implemented within MVC.FX. What is still missing here is actual support wihin Zest.FX. I would opt for setting up the bindings for the EdgeContentPart just as they are set-up for the FXGeometricCurvePart of the MVC Logo example, i.e. bend points can be manipulated within the UI and they move along during a relocation. It is possible, though, that the bend points have to be adjusted after a re-layout. - Animated transitions: I think it would be great to add support for animated transitions within MVC.FX, i.e. the FXTransformOperation could use a JavaFX Transition to perform the transformation change. We could also do this only within Zest.FX by overriding the FXTransformPolicy to animate a relocation caused by a re-layout.
I think we should handle curved connections and animations in distinct bugzillas. Further, we should add a bugzilla zu ensure that the viewport is properly restored after having zoomed into a nested graph and back out again (this is not working correctly yet). As the first two issues are not critical for a zest.core replacement and the latter was not covered by zest.core either, I would tend to resolve this issue after we have created respective bugzillas to keep track of the remaining issues.
Sorry for getting lost; I had some different work to do. However, last week I was trying to adapt one of our projects to the Zest.FX API; it seems really nice, although I have not experimented with the updating the visualization of changes. I'd like to finish this prototype (and I consider the refreshing a very important functionality of the old Zest API). On the other hand, the other issues (animation, curved connections) are safe to move to new issues to keep this ticket understandable.
What we should however ensure before resolving this as fixed, is that all former zest.core examples are migrated to Zest.FX / Layout examples as well, so we do not loose them.
Curved connections (#459314) and animation support (#459315) have been addressed in different bugzillas, so what remains to be done here is to migrate the still missing examples. Matthias, as far as I understand, refresh/update should be covered in a similar way compared to how it was done in zest.core. Could you please elaborate this?
(In reply to Alexander Nyßen from comment #17) > Matthias, as far as I understand, refresh/update should be covered in a > similar way compared to how it was done in zest.core. Could you please > elaborate this? If I understand correctly, Zest.Core is using the SWT refresh/update mechanism. This mechanism is not available within Zest.FX anymore, but instead, the visualization is updated automatically when the content changes. If this is a problem, because you do not want every change to affect the visualization, we probably have to introduce an option to suppress the content synchronization within Zest.FX, so that it is only started manually. Similar to this, layout passes are performed automatically, too. This should probably also be controllable by the user.
(In reply to Zoltan Ujhelyi from comment #15) > However, last week I was trying to adapt one of our projects to the Zest.FX > API; it seems really nice, although I have not experimented with the > updating the visualization of changes. I'd like to finish this prototype > (and I consider the refreshing a very important functionality of the old > Zest API). I am not sure if I completely understand the old API, so I would appreciate if you could elaborate on this further, so I can make sure to migrate it over correctly. Am I correct with my assumption that it should be possible to disable automatic refresh and do it manually?
(In reply to Matthias Wienand from comment #19) > (In reply to Zoltan Ujhelyi from comment #15) > > However, last week I was trying to adapt one of our projects to the Zest.FX > > API; it seems really nice, although I have not experimented with the > > updating the visualization of changes. I'd like to finish this prototype > > (and I consider the refreshing a very important functionality of the old > > Zest API). > > I am not sure if I completely understand the old API, so I would appreciate > if you could elaborate on this further, so I can make sure to migrate it > over correctly. Am I correct with my assumption that it should be possible > to disable automatic refresh and do it manually? I am not sure whether I understand the question correctly, but I do try to describe how Zest in 1.x worked with regards to updates (and I am deliberately leaving out the JFace API as it worked as a layer above this structure). The basic idea was that Zest behaved like it maintained an internal graph model I could update using the methods GraphWidget#addNode, GraphWidget#removeNode, GraphWidget#addConnection, GraphWidget#removeConnection (and maybe even more). The idea was that the moment these calls ended, the displayed user interface was updated (or maybe a little bit later), including re-layouting as necessary. In practice, these methods added/removed displayable widgets directly, without any model between. This allowed a lot of very nice features such as on-the-fly visualizations that changed as soon as the underlying data changed. In contrast to that, Zest.FX seems to me like a static data model display: I can create graph models, but the API does not seem to allow me to update them afterwards. If my model I represent as these graphs changes, the only thing I seem to be able doing is creating an entirely new graph instance, and replace it as the contents of the Viewer. Maybe I am missing something here, as I did not have too much time to check it out... To me, losing this feature would mean an important loss, as we are working with model changes (e.g. in EMF-IncQuery), that are very easy to visualize this way. I hope, this explanation was easier to understand than my previous one. If not, feel free to ask for clarification.
Sorry for the late answer, I was occupied with my exams in the last month. Thank you for the detailed explanation. Currently, you could make changes to the underlying graph model, but those would only affect the visualization after synchronizing the content parts with the contents. This content-synchronization is provided via two operations within MVC: SynchronizeContentChildrenOperation and SynchronizeContentAnchoragesOperation. Obviously, having to manually initiate the content-synchronization is cumbersome. That's why I would suggest to add operations to Zest.FX which resemble the old GraphWidget API: ZestAddNodeOperation, ZestRemoveNodeOperation, ZestAddEdgeOperation, ZestRemoveEdgeOperation. Do you think this would be suitable?
If we already have these two synchronization operations, than I guess the solution could be more elegant: we allow the Graph model to change, and that could trigger a synchronization on model changes. If I recall correctly, we were already talking about using an EMF model (as in KGraph) that provides the same API for the end-user our Graph model does (with the exception that the returned lists are editable), and provides notifications that can be used to trigger content synchronization. Or if we are not using EMF models (or maybe want not), we could extend the current Graph API implementation to provide similar features. I guess such a solution would be more elegant, and might not require the addition of these custom operations.
(In reply to Zoltan Ujhelyi from comment #22) > If we already have these two synchronization operations, than I guess the > solution could be more elegant: we allow the Graph model to change, and that > could trigger a synchronization on model changes. Yes, I agree, we should do it like that. > If I recall correctly, we were already talking about using an EMF model (as > in KGraph) that provides the same API for the end-user our Graph model does > (with the exception that the returned lists are editable), and provides > notifications that can be used to trigger content synchronization. Or if we > are not using EMF models (or maybe want not), we could extend the current > Graph API implementation to provide similar features. We will absolutely have a notification mechanism for this in the future (regardless of whether we will use EMF or not). > I guess such a solution would be more elegant, and might not require the > addition of these custom operations. I would opt for creating those operations nonetheless, to give more control to the user, considering that turning off automatic refresh/layout probably should be possible.
(In reply to Matthias Wienand from comment #23) > (In reply to Zoltan Ujhelyi from comment #22) > > If we already have these two synchronization operations, than I guess the > > If I recall correctly, we were already talking about using an EMF model (as > > in KGraph) that provides the same API for the end-user our Graph model does > > (with the exception that the returned lists are editable), and provides > > notifications that can be used to trigger content synchronization. Or if we > > are not using EMF models (or maybe want not), we could extend the current > > Graph API implementation to provide similar features. > We will absolutely have a notification mechanism for this in the future > (regardless of whether we will use EMF or not). Of course; I just wanted to say that if we plan to use EMF, then it might be a good idea to use it before implementing the notification mechanism. > > I guess such a solution would be more elegant, and might not require the > > addition of these custom operations. > I would opt for creating those operations nonetheless, to give more control > to the user, considering that turning off automatic refresh/layout probably > should be possible. Ok, that is why I said it 'might' not require. Even the notifications can be set up to call these operations if they are more performant.
OK, I created two bugzillas for the automatic refresh upon changes: 1) 461296: Add support for change notifications to GEF4 Graph. 2) 461297: React to the change notifications in Zest.FX. Besides, I migrated the remaining Zest.Core examples to Zest.FX (except the container examples). They can be found in o.e.g4.layout.examples. The code is published on the master branch. Therefore, I resolve this ticket as fixed for 3.10.0M6.
