Re: [gef-dev] Zest FX UI contribution

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

About the JFace API, you have summarized my concerns as well. 

However, for custom data sources the GEF4 Graph model interfaces would not help. In a lot of visualization scenarios, we do not want our model include interfaces from the visualization tools but provide some wrappers. And if I have to create all the wrappers, the JFace-style translation is more elegant (or at least more universally understood).

My current idea would be basically the following:
 * We need an API to translate custom models into GEF4 Graphs; for that the Zest/JFace-style content providers seem useful (e.g. because they already support different kinds of data structures already).
 * The base JFace Label provider only support two elements: labels and icons. Anything else in the content provider is added using Zest-specific layout extensions.
 * The Zest-specific formatting extensions could be simplified by relying on CSS-style formatting: return class and/or id attributes for model elements, and let CSS do the rest.
 * Reusing the JFace content and label providers allows similar data providing interface for the visualizer, that allows similar API used throughout the Eclipse platform (for example, for Zest EMF-generated tree content providers could be reused as a model source). I guess, supporting this is not a strict requirement, but still can be useful.

In summary, I guess, JFace Viewers API support is still not a strict requirement, but I would have troubles designing a different API that is still at least as good for creating the displayable models.

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

On 2014.07.08., at 8:44, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:

> Hi Zoltan,
> 
> thanks for your feedback and ideas. 
> 
> Matthias has already started to work on some of the code-level findings and we have also taken a deeper look at the role of properties in GEF4 Graph and GEF4 Layout (Matthias has posted a first set of ideas yesterday afternoon, all, please comment on these).
> 
> W.r.t. to consuming the JFace-API for Zest.FX.UI I am also quite skeptical. While the content-provider API might yet fit, I am not yet convinced that a label provider is the adequate abstraction if we want to identify nodes mit more details than just a name and an icon. A factory could IMHO be the more flexible approach (but we should discuss this in detail; it is also worth mentioning that there are no JFace dependencies yet, so we would introduce them by this). Regarding your comment on its better suitability for custom data models: what about splitting our current GEF4 Graph model into interfaces (IGraph, INode, etc.) and implementation (Graph, Node)? This way, the interfaces could simply be used if data is to be provided "on the fly". Ultimately we could use these interfaces also in our layout algorithms, thereby replacing the Layout interfaces that are currently there. Matthias proposal to bring the layout interfaces closer to GEF4 Graph would indeed facilitate such a migration. 
> 
> Cheers
> Alexander
> 
> Am 04.07.2014 um 13:55 schrieb 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
>> 
>> _______________________________________________
>> 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
> 
> --  
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nyssen@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
> 
> _______________________________________________
> 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