| Re: [gef-dev] Zest FX UI contribution |
Hi, the scrolling issue (slow, inverse) sounds new to me, I would opt for opening a bug for it. The StackOverflowError on the other hand, is known to me, and I hope to have that one fixed by now. It is caused by two reference points which depend on each other. When the first reference point changes its location, the second reference points recomputes its own location, which in turn triggers recomputation of the first reference point, and so on... I just added moving nodes manually by registering the corresponding policies (FXRelocateOnDragPolicy, FXResizeRelocatePolicy) on the NodeContentPart. If I understand correctly, the GEF4 Graph -> visualization change notification is carried out by the IContentModel which is registered as an adapter for AbstractDomain. When the content of the viewer changes to another Graph object, new content parts are automatically generated via the content part factory. In regards to the static Attr class of the Graph class, I am discontented, too. One more thing that bugs me here, is that you have to convert the keys to strings in order to use them to access the attributes map. I would opt for removing the Attr class altogether and provide the keys which are examined by Zest.FX as constants somewhere in the Zest.FX package. Best regards, Matthias Am 04.07.2014 13:55, schrieb Ujhelyi Zoltán: > 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 > > _______________________________________________ > gef-dev mailing list > gef-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/gef-dev -- Matthias Wienand Auszubildender Telefon: +49 231 98 60 210 Telefax: +49 231 98 60 211 http://www.itemis.de matthias.wienand@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
Attachment:
signature.asc
Description: OpenPGP digital signature