Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 439144

Summary:	Remove GEF4 Layout interfaces and replace uses by direct access to GEF4 Graph.
Product:	[Tools] GEF	Reporter:	Matthias Wienand <matthias.wienand>
Component:	GEF Zest	Assignee:	Matthias Wienand <matthias.wienand>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	nyssen
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Matthias Wienand

2014-07-08 11:47:59 EDT

As a means to prepare the integration of KIELER into GEF4, the GEF4 Layout interfaces should be removed and its uses be replaced by direct access to GEF4 Graph.

Up to now the GEF4 Layout algorithms depend on the GEF4 Layout interfaces to access model data and to provide layout information. This should be changed to rather make direct use of the GEF4 Graph data structure.

Two tasks have to be performed:

1) Bring the GEF4 Layout interfaces closer to GEF4 Graph, i.e. restrict the GEF4 Layout interfaces to only provide a universal property access mechanism. Each GEF4 Layout algorithm can provide a list of input and output properties (possibly in the documentation). When this has been done, the GEF4 Layout interfaces will be pretty close to GEF4 Graph.

2) Replace uses of the GEF4 Layout interfaces by direct access to GEF4 Graph. For this purpose, the GEF4 Graph classes have to be adjusted to allow the manipulation of the graph structure (adding/removing nodes/edges) and its attributes. When this has been done, the GEF4 Layout interfaces can be removed.

Comment 1 Matthias Wienand

2014-07-14 12:22:20 EDT

I mostly restricted the GEF4 Layout interfaces (LayoutContext, EntityLayout, ConnectionLayout, NodeLayout) to the universal property access mechanism and correspondingly adjusted the implementations (Zest.Core and Zest.FX). However, part of the API is still remaining:

1) Static and dynamic layout algorithms
2) Registering event listeners and firing events
3) Pruning and ExpandCollapseManager

I am not entirely sure how to resolve these. I would like to remove dynamic layout from GEF4 Layout. This would remove the necessity of being able to register event listeners / fire events. The static algorithm can be stored in a property. Pruning and ExpandCollapseManager do not belong to the interfaces either. Therefore, I would like to remove those as well (and provide the ExpandCollapseManager in Zest.Core as a property).

What do you think? I can imagine Zest.Core diverging heavily from GEF4 Layout to allow us to clean up the interfaces while keeping Zest.Core functioning. Do you have any objections?

Comment 2 Alexander Nyßen

2014-12-09 14:08:04 EST

I am resolving this as wontfix, as the policy that we have agreed on is:

- use GEF4 graph as the visualization model for Zest and as import/export for DOT
- use GEF4 layout (interfaces) as the layout model to be used by Zest (and to be aligned with KGraph).