<
From version < 8.1 >
edited by cds
on 2013/09/12 11:42
To version < 10.1 >
edited by cds
on 2013/09/16 16:05
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -81,7 +81,7 @@
81 81  (% 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 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.
82 82  
83 83  {{tip}}
84 -The [[KIML page>>doc:Infrastructure for Meta Layout (KIML)]] has a high-level explanation of what happens when during the layout process. To take a look at it if you haven't already – it will make the following concepts easier to understand.
84 +The [[KIML page>>doc:Infrastructure for Meta Layout (KIML)]] has a high-level explanation of what happens when during the layout process. To take a look at it if you haven't already – it will make the following concepts easier to understand. Plus, there's a nice picture that took Miro quite some time to create.
85 85  {{/tip}}
86 86  
87 87  (% style="line-height: 1.4285715;" %)After a 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 layout options to the correct KGraph elements. Sounds easy enough.
... ... @@ -107,28 +107,29 @@
107 107  {{code language="java"}}
108 108  public interface ILayoutConfig {
109 109   int getPriority();
110 -
111 111   void enrich(LayoutContext context);
112 -
113 113   Object getValue(LayoutOptionData<?> optionData, LayoutContext context);
114 -
115 115   void transferValues(KLayoutData layoutData, LayoutContext context);
116 116  } 
117 117  {{/code}}
118 118  
119 -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 lower priority gets overwritten. The other three methods look a bit more obscure, so we have to provide more details on what the options manager does, exactly.
116 +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.
120 120  
121 121  ENRICHING (+ WHAT IS A LAYOUT CONTEXT)
122 122  
123 -TRANSFERRING
120 +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.
124 124  
125 -GETVALUE (for the layout view?)
122 +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.
126 126  
127 127  == (% style="line-height: 1.4285715;" %)Implementing a Layout Configuration(%%) ==
128 128  
129 -(% style="line-height: 1.4285715;" %)deciding what options are applicable depending on the context object; setting the options;
126 +{{warning title="ToDo"}}
127 +deciding what options are applicable depending on the context object; setting the options;
128 +{{/warning}}
130 130  
130 +(% style="line-height: 1.4285715;" %)
131 131  
132 +
132 132  = (% style="line-height: 1.4285715;" %)Programmatically Setting Layout Options(%%) =
133 133  
134 134  {{warning title="ToDo"}}
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -7700960
1 +7701011
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/7700960/Configuring Automatic Layout
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/7701011/Configuring Automatic Layout