Last modified by Alexander Schulz-Rosengarten on 2023/07/11 10:33
<
From version < 16.1 >
edited by msp
on 2014/03/05 16:31
To version < 15.1 >
edited by msp
on 2014/03/05 15:49
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -88,28 +88,39 @@
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 Configurators ==
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 configurator provides:
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 - Object getOptionValue(LayoutOptionData optionData, LayoutContext context);
99 - Collection<IProperty<?>> getAffectedOptions(LayoutContext context);
100 - Object getContextValue(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. The options 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"]] or with [[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"]]. The actual 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 -This may seem complicated, and it is, but the good news is that the vast majority of developers will not need to dig that deep into the layout configuration infrastructure. There are easier ways to specify configurations, as described in the following 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 +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 +
112 +== (% style="line-height: 1.4285715;" %)Implementing a Layout Configuration(%%) ==
113 +
114 +{{warning title="ToDo"}}
115 +deciding what options are applicable depending on the context object; setting the options;
116 +{{/warning}}
117 +
118 +(% style="line-height: 1.4285715;" %)
119 +
120 +
110 110  = (% style="line-height: 1.4285715;" %)Programmatically Setting Layout Options(%%) =
111 111  
112 -(% style="line-height: 1.4285715;" %)So with all these layout configurators available, how do you actually go about setting layout options programmatically? Well, as always: it depends.
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.
113 113  
114 114  
115 115  (% style="line-height: 1.4285715;" %)
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -9469986
1 +9469979
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/9469986/Configuring Automatic Layout
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/9469979/Configuring Automatic Layout