Difference between revisions of "GEF/Meetings/20140702"

Revision as of 08:50, 2 July 2014

The GEF project team and the KIELER project team met by phone on 2 July 2014. Alexander Nyßen (GEF), Christoph Daniel Schulze (KIELER), Stephan Schwiebert (GEF), Miro Spoenemann (KIELER), Fabian Steeg (GEF), Zoltán Ujhelyi (GEF), and Matthias Wienand (GEF) attended.

Alexander:

• Eclipse project for KIELER layout implementation
• Layout metamodel/datamodel
• layout, graph, dot separated
• gap between KIELER layout and GEF4 layout?
• Bring it together! (technical and organizational)

Miro:

• KIELER: cleaner separation of concerns
• improvements of the GEF4 Layout interfaces
• Or switch to a common base (using KGraph interface)
• many methods in gef4 layout interfaces
• graph structure + properties in one set of interfaces
• individual interfaces for the individual algorithms
• KGraph as communication interface

Zoltan:

• Sugiyama layering is very specific, KIELER approach is nice!

Alexander:

• How does KIELER handle Sugiyama layering?

Miro:

• Sugiyama transforms KGraph into its own specific structure
• Providing (computing) layering etc.
• Relevant information is transformed back to the KGraph

Alexander:

• So the layering is not provided

Miro:

• KGraph very simple: Edges, Nodes, Ports
• internal graph structure for each algorithm

Fabian:

• GEF4 äquivalent for KGraph is GEF4 Graph

Miro:

• KGraph data = GEF4 Graph attributes

Alexander:

• Similar ideas:
• data/layout separation
• Generic data attaching mechanism
• But how about additional input which cannot be deduced?
• Maybe add additional data to the data model (GEF4 Graph / KIELER KGraph)?
• And what about grouping elements?
• Layer = subgraph (dot)

Miro:

• Each node can contain sub-nodes in KGraph (nested graphs)
• Yes, give input through properties / attributes
• Exception: hierarchy trees: cumbersome, but worked.

Alexander:

• Do you think GEF4 Layout algorithms could fit KGraph structure?

Miro:

• Some of the code could possibly be implemented directly on the KGraph
• Sugiyama implementation uses dummy nodes, etc. => duplicate structure like in KIELER would be better

Miro:

• Main difference (Graph/KGraph): KGraph uses EMF data structure
• pro: customer got a problem with layout => add method to serialize KGraph structure => analyze problem

Alexander:

• DOT component (import/export generic graph model and DOT language)
• same purpose as serialization?

Miro:

• interchange always useful
• KGraph got parser and serializer for DOT
• integration with GraphViz that way

Miro:

• subgraph kinds not differentiated
• structure allows nodes to have sub-nodes
• every node stores the layout algorithm which it belongs to
• useful to be able to apply different algorithms on different hierarchy levels

Christoph:

• Dynamic vs. Static layout algorithm,
• GEF4 layout can react to graph structure changes

Zoltan:

Miro:

• Single layout call
• either take previous layout information or not
• no explicit mechanism for dynamic layout algorithms
• KIELER configured via properties (attached to input KGraph)

Alexander:

• GEF4 Layout algorithms contributed over time
• Therefore, no common interfaces from the beginning)
• correct approach: use generic properties
• DOT, Graph, Layout => KGraph-Dot, KGraph, KIELER algorithms
• How does KIELER transport information back to KGraph?

Miro:

• KIELER does also use the same KGraph for output as for input
• main difference: applyLayout() vs. applyLayout(KGraph).

Alexander:

• Dynamic layout requires guarding some of the layout context methods

Miro:

• Don't rely on an internal state, but compute everything on applyLayout.

Alexander:

• Similarieties in DOT and Graph part
• Differences with regard to layout interfaces and implementations
• Work on GEF4 Layout component separately from the other parts
• We can combine KGraph with GEF4 Layout (less effort)
• first starting point: interoperability

Fabian:

• Overlapping concepts
• KIELER become part of GEF would be beneficial

Miro:

• KIELER team wants to manage a separate Eclipse project

Alexander:

• own eclipse project for KIELER seems reasonable
• GEF4 Graph could consume KGraph
• KIELER eclipse project could concentrate on layout implementations
• at least: transform between graph, Kgraph
• GEF can also provide visualization for the graph structure (Zest)

Miro:

• transformation always possible
• share common data structure is a good idea
• transformation not always trivial
• direct integration of KGraph in visualization framework absolutely beneficial
• two projects: core classes and interfaces, KGraph
• can be merged into one project for the KIELER data structure

Alexander:

• Merge KGraph and GEF4 Graph
• Adapt layout and visualization to that data structure
• KIELER layout project will use that as well

Miro:

• Rework data model in the merge process (take the chance)

Alexander:

• Let's work on a contribution to merge KGraph into GEF4 Graph

Miro:

• EMF basis in KGraph vs. Plain Java approach in GEF4 Graph

Fabian:

• GEF4 Graph resulted from GEF4 DOT
• prefer plain Java

Alexander:

• MVC and Zest view: keep in mind intention to support stand alone editors
• not bound to Eclipse ecosystem
• for example: in the web
• preference for plain Java
• but we can live with the dependency

Miro:

• EMF not bound to Eclipse framework
• beneficial for validation and model consistency
• another team meeting for the organizational stuff?
• Discussion on the mailing list for merging into GEF4 Graph?

Alexander:

• OK, discussion: Replace current implementation or extend it?

Fabian:

• add to discussion: Dependency to EMF => dependency on Eclipse platform

Christoph:

• EMF beneficial for testing and many other things
• EMF is useful, but conclude in the discussion on the mailing list

Miro:

• Internal discussion first
• Later discussion on the mailing list, probably next week

Alexander ended the discussion about KIELER. Thank you for your participation! The GEF project team stayed on to discuss the GEF release for Eclipse Mars.

Alexander:

• Mars planning
• Remain proper Eclipse citizens, but only publishing provisional API
• e4 and p2 did it: mark all packages as internal
• Or: publish an API that we maybe drop next year

Fabian:

• Prefer not to be bound to the API

Benutzer 1: + Zoltan: +

Alexander:

• Expose to be real API, rename provisional API to internal and mark appropriately
• one commit for all plugins
• Mars release: achieve something self-contained, i.e. Get rid of GEF 3.x dependencies (Draw2d)
• GEF4 Zest.FX misses features

Matthias:

• Subgraph and nested graph rendering missing

Fabian:

• Subgraph concept important? Or delete it?

Zoltan:

• Never used subgraphs
• Nested graphs needed!

Alexander:

• things missing:
• Implement nested graphs
• implement subgraphs
• split eclipse view from zest.fx rendering

Zoltan:

• Not sure about the JFace API again

Zoltan:

• Mapping between JFace content provider and graph structure

Alexander:

• Zest.FX = JavaFX based renderer for GEF4 Graph structure
• Zest.FX.UI = integration to JFace API

Fabian:

• Subgraph = expand/collapse nodes
• Graph-Container / nested graph = real nested graph
• Starting point: plain graph + subgraphs
• Later on: nested graph

Zoltan:

• Subgraph concept not really useful
• nested graphs really needed

Alexander:

• Create new bugs for the issues
• 1: Zest.FX component
• 2: Graph structure
• 3: KGraph structure (KIELER)
• In parallel: investigate eclipse ui integration for zest.fx

Zoltan:

• Missing visualization features in Zest.FX
• Get in touch with Matthias

Alexander:

• Anything else to discuss? (No...)
• Plan more team calls: once per month?

Benutzer 1:

• appreciate more team calls
• closer involvement

Alexander:

• Doodle on last week on each month
• team meeting in following month