Changes for page Configuring Automatic Layout
Last modified by Alexander Schulz-Rosengarten on 2023/07/11 10:33
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Objects (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -72,11 +72,11 @@ 72 72 73 73 (% style="line-height: 1.4285715;" %)This tells KIML that the defined layout algorithm supports the border spacing option. And even more, it overrides the default value declared by the layout option and sets it to 20. 74 74 75 -= (% style="line-height: 1.4285715;" %)The Layout Option Manager(%%) = 75 += (% style="line-height: 1.4285715;" %)The Layout Options Manager(%%) = 76 76 77 -(% style="line-height: 1.4285715;" %)By now, we have an idea of what layout options do and why they are important in the first place. However, we haven't looked at how layout options end up on [[KGraph>>doc:KGraph Meta Model]] elements yet. This is where the [[{{code language="none"}}LayoutOptionManager{{/code}}>>url:http://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml. service/src/de/cau/cs/kieler/kiml/service/LayoutOptionManager.java||shape="rect"]] comes in.77 +(% style="line-height: 1.4285715;" %)By now, we have an idea of what layout options do and why they are important in the first place. However, we haven't looked at how layout options end up on [[KGraph>>doc:KGraph Meta Model]] elements yet. This is where the [[{{code language="none"}}LayoutOptionsManager{{/code}}>>url:http://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml.ui/src/de/cau/cs/kieler/kiml/ui/service/LayoutOptionManager.java||shape="rect"]] comes in. 78 78 79 -(% style="line-height: 1.4285715;" %)After a diagram layout manager has finished turning a given diagram into its KGraph representation, the layout option manager is asked to enrich the KGraph elements with layout options. The option values can come from different sources: the user might have set some using the layout view; there might be some defaults for certain kinds of diagrams; or the programmer might have decided to attach some layout options to certain elements for just this one layout run. Whatever the source, the options manager is in charge of collecting all these layout option values and making sure they find their way to the correct KGraph element. To start off with a clean plate, it first makes sure there are no layout options attached to the KGraph elements. It then does two things: collect every eligible source of layout options, and transfer values of layout options to the associated KGraph elements. Sounds easy enough. 79 +(% style="line-height: 1.4285715;" %)After a diagram layout manager has finished turning a given diagram into its KGraph representation, the layout options manager is asked to enrich the KGraph elements with layout options. The option values can come from different sources: the user might have set some using the layout view; there might be some defaults for certain kinds of diagrams; or the programmer might have decided to attach some layout options to certain elements for just this one layout run. Whatever the source, the options manager is in charge of collecting all these layout option values and making sure they find their way to the correct KGraph element. To start off with a clean plate, it first makes sure there are no layout options attached to the KGraph elements. It then does two things: collect every eligible source of layout options, and transfer values of layout options to the associated KGraph elements. Sounds easy enough. 80 80 81 81 (% style="line-height: 1.4285715;" %)The question remains how the layout options sources work. Each source is represented by a class that implements the [[{{code language="none"}}ILayoutConfig{{/code}}>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/config/ILayoutConfig.java||shape="rect"]] interface, called a //layout configurator//. KIML currently provides the following layout configurators, each representing a particular source of layout options, listed here in order of increasing priority: 82 82 ... ... @@ -88,47 +88,47 @@ 88 88 89 89 The options manager collects all available and applicable layout configurators and sorts them by priority. For every graph element, each configurator is asked to provide layout options, starting with the one with lowest priority and working through the priority chain. Hereby configurators with higher priority are able to override values set by those with lower priority. 90 90 91 -== A Few Details on Layout Configurato rs ==91 +== A Few Details on Layout Configurations == 92 92 93 -What we just learned is a bit of a simplification of what happens. Before we look at the details, let's take a look at the methods each layout configurato rprovides:93 +What we just learned is a bit of a simplification of what happens. Before we look at the details, let's take a look at the methods each layout configuration provides: 94 94 95 95 {{code language="java"}} 96 96 public interface ILayoutConfig { 97 97 int getPriority(); 98 - ObjectgetOptionValue(LayoutOptionData optionData, LayoutContext context);99 - Collection<IProperty<?>>getAffectedOptions(LayoutContext context);100 - ObjectgetContextValue(IProperty<?>property, LayoutContext context);98 + void enrich(LayoutContext context); 99 + Object getValue(LayoutOptionData<?> optionData, LayoutContext context); 100 + void transferValues(KLayoutData layoutData, LayoutContext context); 101 101 } 102 102 {{/code}} 103 103 104 -It is not hard to guess what {{code language="none"}}getPriority(){{/code}} does: it returns the priority a given layout configuration has. If two layout configurations set a layout option to different values on a given graph element, the value set by the configuration with higher priority wins. 104 +It is not hard to guess what {{code language="none"}}getPriority(){{/code}} does: it returns the priority a given layout configuration has. If two layout configurations set a layout option to different values on a given graph element, the value set by the configuration with higher priority wins. The other three methods look a bit more obscure, so we have to provide more details on what the options manager does, exactly. 105 105 106 - The interface discerns between //option// values and //context// values. Option values are what we have been talking about all the time, values assigned to layout options. Which particular values the configurator should apply depends on the given [[LayoutContext>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/config/LayoutContext.java||shape="rect"]], which is a property holder with references to the diagram element currently in focus. For instance, the object representing an element in the diagram viewer is accessed with {{code language="none"}}context.getProperty(LayoutContext.DIAGRAM_PART){{/code}}. Similarly, the corresponding KGraph element is mapped to the property {{code language="none"}}LayoutContext.GRAPH_ELEM{{/code}}, and the domain model element is mapped to {{code language="none"}}LayoutContext.DOMAIN_MODEL{{/code}}.Each configurator is free to put additional information into the context, caching it for faster access and enabling to communicate it to other configurators. {{code language="none"}}getAffectedOptions(LayoutContext){{/code}}should return a collection of layout options for which the configurator yields non-null values with respect to the given context.Theoptions can be referenced either with [[LayoutOptionData>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/LayoutOptionData.java||shape="rect"]] instances obtained from the [[LayoutMetaDataService>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/LayoutMetaDataService.java||shape="rect"]]orwith [[Property>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.core/src/de/cau/cs/kieler/core/properties/Property.java||shape="rect"]] instances from the constants defined in [[LayoutOptions>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/options/LayoutOptions.java||shape="rect"]].Theactual value for a layout option is queried with {{code language="none"}}getOptionValue(LayoutOptionData, LayoutContext){{/code}}. The method {{code language="none"}}getContextValue(IProperty, LayoutContext){{/code}}, in contrast, is used to obtain more detailed information on the given context. For instance, the context may contain a reference to an element of the diagram viewer; only a specialized configurator made for that diagram viewer knows how to extract a reference to the corresponding domain model element from the given diagram element, so it can encode this knowledge in {{code language="none"}}getContextValue(…){{/code}} by returning the domain model element when the given property corresponds to LayoutContext.DOMAIN_MODEL.106 +ENRICHING (+ WHAT IS A LAYOUT CONTEXT) 107 107 108 -Th ismayseemcomplicated,andit is,but the goodnewsis thatthe vastmajorityof developerswillnotneedtodigthatdeepintothelayout configurationinfrastructure.Thereare easier waystospecifyconfigurations,asbed inhefollowing section.108 +The {{code language="none"}}transferValues(...){{/code}} method is the main workhorse of the interface. This is where a KGraph element, identified by the given layout context, is equipped with the layout option values a layout configuration deems necessary. It thus becomes the most important part of a layout configuration that you absolutely have to implement, no excuses. If for example every {{code language="none"}}KNode{{/code}} should have its port constraints set to {{code language="none"}}FIXED_POS{{/code}}, this is the place to do it. 109 109 110 - =(%style="line-height:1.4285715;"%)ProgrammaticallySetting LayoutOptions(%%)=110 +With all these layout configurations active, it's by no means clear which layout option values KGraph elements will end up with during the layout process. Enter the {{code language="none"}}getValue(...){{/code}} method. For a given element and layout option, it returns the value it would set on the element if {{code language="none"}}transferValues(...){{/code}} was called. This method is mainly used by the Layout view to inform the user about the layout option values of whatever graph element he (or she) has clicked on. It is also the method you can safely neglect to implement if your final product won't include the layout view anyway. 111 111 112 -(% style="line-height: 1.4285715;" %) So with all theselayout configurators available, how do you actually go about settingvaluesfor layout options programmatically? Well, as always: it depends.112 +== (% style="line-height: 1.4285715;" %)Implementing a Layout Configuration(%%) == 113 113 114 -== (% style="line-height: 1.4285715;" %)Using the Extension Point(%%) == 114 +{{warning title="ToDo"}} 115 +deciding what options are applicable depending on the context object; setting the options; 116 +{{/warning}} 115 115 116 -(% style="line-height: 1.4285715;" %) The recommended way to configure your layout is to use the {{code language="none"}}layoutConfigs{{/code}} extension point. It offers three different kinds of configurations, explained in the following.118 +(% style="line-height: 1.4285715;" %) 117 117 118 -=== (% style="line-height: 1.4285715;" %)staticConfig(%%) === 119 119 120 -(% style="line-height: 1.4285715;" %) A {{code language="none"}}staticConfig{{/code}} elementcan setonevalue for one layoutoptionin the context of a particular diagram element type. Let'ssee an example:121 += (% style="line-height: 1.4285715;" %)Programmatically Setting Layout Options(%%) = 121 121 122 -{{code language="xml"}} 123 - <staticConfig 124 - class="org.eclipse.emf.ecore.EReference" 125 - option="de.cau.cs.kieler.edgeType" 126 - value="ASSOCIATION"> 127 - </staticConfig> 128 -{{/code}} 123 +(% style="line-height: 1.4285715;" %)So with all these layout configurations available, how do you actually go about setting layout options programmatically? Well, as always: it depends. 129 129 130 -(% style="line-height: 1.4285715;" %)Here {{code language="none"}}class{{/code}} refers to a domain model class, in this case the {{code language="none"}}EReference{{/code}} class from the Ecore meta model defined by EMF, and {{code language="none"}}option{{/code}} refers to a layout option through its identifier. The meaning of this declaration is that whenever automatic layout is requested for an Ecore class diagram, the {{code language="none"}}edgeType{{/code}} option is set to {{code language="none"}}ASSOCIATION{{/code}}(%%) for all edges linked to instances of {{code language="none"}}EReference{{/code}}. Since the domain model (//abstract syntax//) is independent of the specific diagram viewer (//concrete syntax//), this configuration is applied to all diagram viewers that use the Ecore meta model. 131 131 132 - 126 +(% style="line-height: 1.4285715;" %) 133 133 134 -(% style="line-height: 1.4285715;" %) 128 + 129 +{{warning title="ToDo"}} 130 +Write this section. This will be about when to use the different kinds of layout configurations, mainly {{code language="none"}}SemanticLayoutConfig{{/code}} and {{code language="none"}}VolatileLayoutConfig{{/code}}. 131 +{{/warning}} 132 + 133 +(% style="line-height: 1.4285715;" %) 134 +
- Confluence.Code.ConfluencePageClass[0]
-
- Id
-
... ... @@ -1,1 +1,1 @@ 1 -94699 881 +9469979 - URL
-
... ... @@ -1,1 +1,1 @@ 1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/94699 88/Configuring Automatic Layout1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/9469979/Configuring Automatic Layout