×

Status message

This proposal has been approved and the Eclipse Layout Kernel project has been created.

ELK - Eclipse Layout Kernel

Basics
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project: 
Background: 

The KIELER Infrastructure for Meta-Layout (KIML) and the KIELER Layouters (KLay) projects both started as research projects at the Real-Time and Embedded Systems Group, Kiel University. The latter provides pure-Java implementations of several layout algorithms, while the former provides an infrastructure to connect those algorithms to Eclipse-based graphical editors and viewing frameworks. Layout algorithms are a research focus of our research group at Kiel University, and both technologies are already part of several open-source and closed-source commercial applications.

One of those applications is Papyrus, for which our group developed a layout algorithm for UML sequence diagrams. This collaboration prompted us to investigate becoming an official Eclipse project, which would facilitate incorporating automatic layout into Eclipse projects.

Scope: 

The scope of this project includes two areas: layout algorithms and the actual layout kernel / infrastructure. Layout algorithms includes Java implementations of layout algorithms as well as interfaces to existing libraries of layout algorithms. The layout kernel includes the basic framework to connect graphical editors to layout algorithms. This includes a robust data structure to represent graphs and annotate them with layout configuration information.

The scope of this project specifically excludes the development of graphical editing frameworks, or any kind of displaying infrastructure for that matter.

Description: 

Graphical editors are popular for visualizing concepts and systems. However, just being graphical in nature does not automatically make a diagram easy to understand. Its usefulness much rather depends on how well its elements are placed and how well the links connecting its elements are routed. The placement of elements and the routing of links is what we call the layout of a diagram. Getting the layout right is labour intensive and time consuming. Automatic layout aims to free users from this task by providing algorithms that compute layouts for them.

This project provides both layout algorithms and a framework that connects them to diagram editors. To enable automatic layout for your editor, developers simply have to provide code that transforms diagrams into a format the framework understands, and code that applies the computed layouts back to the diagrams.

Why Here?: 

This project will augment Eclipse with an editor-independent layout framework. Since our layout infrastructure is based on Eclipse technology, becoming an official Eclipse project is the next logical step.

One goal is that all major editing frameworks will interface with the layout framework, as far as possible. Such interfaces have already been implemented for GMF-based editors and, to a lesser extent, for Graphiti-based editors.

Another goal is to add the perspective of automatic layout to design discussions to make it easier for projects to add layout support. We have already started discussions in that direction with the developers of GEF 4.

Project Scheduling: 

An initial contribution can be expected shortly after the project's acceptance. The main and most labour intensive challenge here will be to do some restructuring and to properly rename all plug-ins, extension points, and packages.

Afterwards, we will take the opportunity to refactor some of the core infrastructure (as outlined below in Future Work). Once that refactoring is finished, we expect to be ready to produce a first release.

Future Work: 

The central data structure of the layout infrastructure (the KGraph) was designed years ago. The design goal was for it to be a generic representation of graphs where each element could be augmented with further data. Layout information fell under the "further data" category. However, in the new project, the only purpose of the KGraph will be to serve as a basic data structure for automatic layout. Thus, the KGraph will be the first thing we will overhaul.

One focus of our research group continues to be layout algorithms. They will thus see further development. Specific areas of development will be decided upon on a shorter term basis.

People
Project Leads: 
Committers: 
Interested Parties: 

So far, the Papyrus team and the Graphical Editing Framework team have expressed specific interest in our project. However, there are a number of other users of KIELER (academic and commercial) interested in this becoming an official Eclipse project, among them:

  • National Instruments
  • Bosch/ETAS
  • Sigasi
  • Infineon
  • Sirius
  • Atos
Source Code
Initial Contribution: 

The Embedded and Real-Time System Group, Kiel University, holds the rights to all of the submitted code. This is backed up by agreements signed by all developers involved.

We intend to have the initial contribution consist of the following parts (we use the current names here, which may change if this project gets accepted):

  • KGraph. This is the central data structure used by the layout infrastructure. This is basically an EMF meta-model with a few additions in the code generated from the model.
  • KIML. The KIELER Infrastructure for Meta-Layout acts as the KGraph-based interface between graphical views / editors and layout algorithms. It is also responsible for managing layout options that configure the behaviour of layout algorithms. This includes presenting layout options to the user via a view similar to the Properties view as well as providing mechanisms for the configuration of default layout options.
  • KLay. The KIELER Layouters project includes implementations of different layout algorithms. Since the algorithms are purely Java-based, they can also be used outside of Eclipse. This is the part of the project that our research group will be working on most.

Most contributions to this project currently comes from members of our research group and our students (whose submissions are filtered through members of our research group). The projects that employ our automatic layout technologies mostly contribute bug reports and feature requests.

Source Repository Type: 
Guilherme Silveira's picture

Hi,

There are several users that use the layout algorithms with external applications like Simulink and Scade

It is important to keep this use case in mind. 

The models used in these applications can be very different since they are very big, have several inputs e tend to be "low level"

 

 

Pierre-Charles David's picture

Hi,

Sirius would also be interested by improved layout algorithms. Could you add us as interested parties?

Thanks.

 

Christoph Daniel Schulze's picture

Sure thing, thanks for your interest. :)

Wolfgang Zeller's picture

We are currently searching for a layout algorithm for a high-sophisticated graphical editor embedded into an IDE based on the Eclipse RCP Framework.

The graphical editor is based on EMF and JavaFX and thus using some bleeding-edge technologies. Is there already a roadmap for the project or is it in its early proposal state?

Regards,

Wolfgang Zeller
Product Owner logi.CAD 3
http://www.logicals.com

Christoph Daniel Schulze's picture

Hi Wolfgang,

there's no explicit roadmap yet in terms of supporting additional graphics infrastructures. Here at Kiel University, we are focussing mostly on the layout algorithm side of things for the moment. However, once the project is off the ground we should have a chat about what would be necessary to integrate layout support into your graphical editor.

Cheers,

Christoph Daniel