[gef-dev] Zest FX UI contribution

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi all,

I have been thinking in the last two days about the Zest.FX.UI component, and how it should behave, and I also would like to share my experiences with the new Zest.FX component. First of all, thanks for the nice demo, it is nice to have something demonstrating how Zest.FX behaves. However, I have some feedback as well:
 1. For some reason, scrolling (if required), works very differently than anything else in my workspace. I am using OS X 10.9, and have installed Java 8 with Luna (if that is important). First of all, scrolling is _very_ slow. Second, for some reason, scrolling works inversely as I'm used to - like the natural scrolling option in OSX (that I always turn off).
 2. During scrolling sometimes I got very strange exceptions (e.g. one is shown in https://gist.github.com/ujhelyiz/8dd10418552b1c8c9b5a).
 3. I don't know how hard it is to support moving nodes manually (e.g. via drag-and-drop) after they were layouted by an algorithm, but it is not supported yet.

And I was thinking about the exact role of the fx.ui component as well, and found only a single use case that is not easily supported by the current API: providing a source model that needs to be translated to the GEF4 Graph model. For this, two kind of functionality is needed inside:
 1. Providing traceability to the source model elements. Luckily, this can be handled via a specific attribute in the model.
 2. Providing change notification support: source model -> GEF4 Graph model -> visualization. The first one can be done similarly to JFace Viewers inside the Content/Label providers; the second one needs to be provided by Zest (and after looking at the code for quite a time, I did not find the way how to implement it).

My question here is whether it is worth reusing the _entire_ JFace Viewers API for this limited use case, or just provide a higher-level set of factory classes. If we support the JFace-style programming model, the JFace Content/Label providers should simply create a GEF Graph, and give it to an underlying visualization; however, the same functionality could be put into a specific ContentPartFactory as well. The more I think about this, I tend to think about the JFace-style solution would be more useful for custom data models; but in this case we should aim at merging somehow the Graph and LayoutContext models to avoid repeated storage and copying between the different representations.

Finally, I have a code-level suggestion as well: I really don't like the static Attr class of the Graph class. It contains two enums, where the values are (1) not the complete set of supported keys/values, and (2) not all key-value pairs are supported... This is especially problematic for values. I either suggest using constants instead of enums, or providing more enums for values, and keeping only corresponding values in a single enum (e.g. LINE_DASH, LINE_DOT, LINE_SOLID, LINE_DASHDOT, LINE_DASHDOTDOT as LINE_STYLES , that can apply to both edges and node borders or DIRECTED/UNDIRECTED as both a graph and edge parameter).

I see that I can fix the attribute representation, but I have no deep understanding of the JavaFX/SwtFX API to fix the first feedbacks. Should I open bugs for them?

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics