Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
ELK - Eclipse Layout Kernel
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.
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.
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.
All of our code has always been released under EPL 1.0. All committers have signed an agreement to release their code as open source software. Thus, most of the code should be clear of legal issues.
An exception is our distribution of the OGDF layout library in an Eclipse plug-in. The library is released under GPL 2 or 3. It may be necessary to exclude the OGDF integration from the Eclipse project and to continue making it available through its current update site.
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.
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.
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.
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
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.
- Log in to post comments
- Log in to post comments
Layout algorithm needed for industrial application
Submitted by Wolfgang Zeller on Sat, 05/30/2015 - 09:16
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
Hi Wolfgang,
Submitted by Christoph Dani… on Thu, 06/04/2015 - 08:57
In reply to Layout algorithm needed for industrial application by Wolfgang Zeller
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
Hi,
Submitted by Pierre-Charles David on Thu, 06/04/2015 - 04:09
Hi,
Sirius would also be interested by improved layout algorithms. Could you add us as interested parties?
Thanks.
Sure thing, thanks for your
Submitted by Christoph Dani… on Thu, 06/04/2015 - 08:55
In reply to Hi, by Pierre-Charles David
Sure thing, thanks for your interest. :)
External Integrations
Submitted by Guilherme Silveira on Tue, 11/17/2015 - 07:01
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"