Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

GEF/Meetings/20140702

< GEF

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:

  • What should be the scope of an eclipse project for the KIELER layout implementations
  • What is the layout model used in KIELER?
  • GEF4 separates a layout model, a graph data structure and a DOT parser/generator for the graph data structure
  • How big is the gap between KIELER layout and GEF4 layout?
  • We should bring it together (technical and organizational)

Miro:

  • KIELER: cleaner separation of concerns
  • Either improve GEF4 layout interfaces
  • Or switch to a common base (maybe KGraph)
  • Currently too many methods in gef4 layout interfaces
  • Graph structure + properties belong to one set of interfaces
  • Specific layout algorithms can transform the common model into a specific model
  • KGraph as common interface

Zoltan:

  • Sugiyama layering is very specific
  • The KIELER approach can handle such specifics without problems

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 as input to the algorithm

Miro:

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

Fabian:

  • GEF4 equivalent for KGraph is GEF4 Graph

Miro:

  • KGraph properties = 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 to represent nested graphs
  • If an algorithm needs additional input, this is given via properties

Alexander:

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

Miro:

  • Some of the code could possibly be implemented directly on the KGraph interface
  • Other algorithms more complicated, for example, Sugiyama implementation uses dummy nodes, etc.
  • In the complicated cases a duplicate structure like in KIELER would probably be beneficial

Miro:

  • Main difference (Graph/KGraph): KGraph uses EMF data structure
  • Has proved to be beneficial in various scenarios
  • Example: 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
  • KIELER contains a DOT to KGraph parser and KGraph to DOT serializer
  • Integration with GraphViz that wayAlexander

Matthias:

  • What about different kinds of subgraphs?
  • Subgraphs as a means to group multiple nodes and provide one single visualization for them
  • Nested graphs as in Zest.Core graph containers

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:

  • GEF4 layout differentiates dynamic and static layout algorithms
  • GEF4 layout can react to graph structure changes
  • KIELER is simpler in that regard

Miro:

  • KIELER provides a single layout call
  • The algorithm can decide to use previous layout information or not
  • No explicit mechanism for dynamic layout algorithms
  • Algorithms are configured via properties (attached to input KGraph)

Alexander:

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

Miro:

  • KIELER uses the same KGraph for output as for input
  • the KGraph is given as a parameter to applyLayout(KGraph)

Alexander:

  • Dynamic layout requires guarding some of the layout context methods

Miro:

  • KIELER does not explicitly provide dynamic layouting
  • An algorithm does not rely on internal state, but only on the given KGraph

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 (layout implementations using KGraph)
  • 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 provide visualization for the graph structure

Miro:

  • Transformation always possible
  • Share common data structure is a good idea
  • Transformation not always trivial
  • Direct integration of KGraph in the visualization framework absolutely beneficial
  • Two projects: core classes and interfaces, KGraph
  • Can be merged into one project for the KIELER data structure

Alexander:

  • Propose: 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:

  • OK, plan contribution to merge KGraph into GEF4 Graph

Miro:

  • Decision: EMF basis in KGraph vs. plain Java object 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 (if necessary)

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 on the mailing list: Replace current implementation or extend it?

Fabian:

  • Dependency to EMF => dependency on Eclipse platform
  • Add to discussion: EMF vs. plain Java

Christoph:

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

Miro:

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

The discussion on the KIELER project ended. 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

Stephan: + Zoltan: +

Alexander:

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

Matthias:

  • Subgraph and nested graph rendering missing

Fabian:

  • Graph containers (nested graphs) caused many problems in the past
  • Is the concept important, or can we remove it?

Zoltan:

  • Subgraph concept not really useful
  • Nested graphs important!

Alexander:

  • things missing:
  • Implement nested graphs
  • implement subgraphs
  • Split eclipse view from Zest.FX rendering

Zoltan:

  • Not sure about the JFace API
  • Mapping between JFace content provider and graph structure needed

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

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

Matthias:

  • I will create a bug ticket for the missing Zest.FX features
  • We can continue the discussion there

Alexander:

  • Plan more team calls: once per month?

Stephan:

  • appreciate more team calls
  • closer involvement

Alexander:

  • Doodle on last week on each month
  • team meeting in following month
Retrieved from "https://wiki.eclipse.org/index.php?title=GEF/Meetings/20140702&oldid=366302"

This page was last modified 09:49, 2 July 2014 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top