Changes for page Configuring Automatic Layout
Last modified by Alexander Schulz-Rosengarten on 2023/07/11 10:33
Summary
-
Page properties (3 modified, 0 added, 0 removed)
-
Objects (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,0 +1,1 @@ 1 +KIELER.Home.Discontinued Projects.Infrastructure for Meta Layout (KIML).WebHome - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. msp1 +XWiki.uru - Content
-
... ... @@ -7,7 +7,7 @@ 7 7 * How do layout options end up in KGraph elements? 8 8 * How can I set layout options on elements programmatically? 9 9 10 -This page does not list the available layout options, and neither does it explain any of them. You can find a list of layout options provided by KIML [[over here>>doc:KIML Layout Options]]. 10 +This page does not list the available layout options, and neither does it explain any of them. You can find a list of layout options provided by KIML [[over here>>doc:KIELER.KIML Layout Options]]. 11 11 12 12 13 13 ... ... @@ -54,7 +54,6 @@ 54 54 * (% style="line-height: 1.4285715;" %){{code language="none"}}upperBound{{/code}} – An optional upper bound on the values of this layout option. 55 55 * (% style="line-height: 1.4285715;" %){{code language="none"}}variance{{/code}} – An optional variance for values of this layout option. The variance is taken as multiplier for Gaussian distributions when new values are determined. Options with uniform distibution, such as Boolean or enumeration types, do not need a variance value, since all values have equal probability. A variance of 0 implies that the option shall not be used in automatic configuration, regardless of its type. 56 56 57 - 58 58 (% style="line-height: 1.4285715;" %)The latter three attributes are used when a layout configuration is determined automatically, e.g. with an evolutionary algorithm. They are mainly meant for scientific experiments and can be ignored in most applications. 59 59 60 60 (% style="line-height: 1.4285715;" %)If a layout algorithm supports a particular layout option, it must tell KIML so. Here's an example: ... ... @@ -76,7 +76,7 @@ 76 76 77 77 = (% style="line-height: 1.4285715;" %)The Layout Option Manager(%%) = 78 78 79 -(% 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. If you are not interested in the internal details, but want to configure automatic layout for your diagram viewer or editor, you may skip this section and proceed to [[programmatically setting layout options>>doc:||anchor="programmatic-config"]]. 78 +(% 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:KIELER.Home.Discontinued Projects.Infrastructure for Meta Layout (KIML).KGraph Meta Model.WebHome]] 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. If you are not interested in the internal details, but want to configure automatic layout for your diagram viewer or editor, you may skip this section and proceed to [[programmatically setting layout options>>doc:||anchor="programmatic-config"]]. 80 80 81 81 (% 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. 82 82 ... ... @@ -168,6 +168,14 @@ 168 168 169 169 A further use of diagram types is for the selection of layout algorithms: a layout algorithm may declare that is is especially suited to process diagrams of certain type //t//. If the diagram type //t// is assigned to a diagram viewer, the most suitable layout algorithm is chosen automatically for that viewer. 170 170 170 +The following diagram types are predefined in KIML: 171 + 172 +* de.cau.cs.kieler.layout.diagrams.stateMachine – All kinds of state machines, statecharts, etc. 173 +* de.cau.cs.kieler.layout.diagrams.dataFlow – All kinds of data flow diagrams, e.g. actor diagrams, block diagrams, certain component diagrams, etc. 174 +* de.cau.cs.kieler.layout.diagrams.classDiagram – Class diagrams as defined by the UML, but also meta model diagrams such as the Ecore format. 175 +* de.cau.cs.kieler.layout.diagrams.usecaseDiagram – UML use case diagrams. 176 +* de.cau.cs.kieler.layout.diagrams.boxes – Unconnected boxes (graphs with no edges), e.g. parallel regions in statecharts. 177 + 171 171 === semanticConfig === 172 172 173 173 A {{code language="none"}}semanticConfig{{/code}} element registers a subclass of [[SemanticLayoutConfig>>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/SemanticLayoutConfig.java||shape="rect"]]: ... ... @@ -263,4 +263,19 @@ 263 263 264 264 If you are uncertain about which value to use for {{code language="none"}}PRIORITY{{/code}}, take something like 25. 265 265 266 - 273 +== Adding Support for the Layout View == 274 + 275 +The Layout View empowers users to directly modify the layout configuration for the currently viewed diagram. This power, however, comes with a price. Tool developers implementing a [[IDiagramLayoutManager>>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/IDiagramLayoutManager.java||shape="rect"]] additionally have to provide an implementation of [[IMutableLayoutConfig>>url:http://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml/src/de/cau/cs/kieler/kiml/config/IMutableLayoutConfig.java||shape="rect"]] that loads and saves layout option values in a way that they can be stored persistently with the respective diagram. Good examples of such configurators are [[GmfLayoutConfig>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml.gmf/src/de/cau/cs/kieler/kiml/gmf/GmfLayoutConfig.java||shape="rect"]] and [[GraphitiLayoutConfig>>url:https://git.rtsys.informatik.uni-kiel.de/projects/KIELER/repos/pragmatics/browse/plugins/de.cau.cs.kieler.kiml.graphiti/src/de/cau/cs/kieler/kiml/graphiti/GraphitiLayoutConfig.java||shape="rect"]] for GMF and Graphiti diagrams, respectively. The GMF implementation stores option values as //styles// in the GMF //Notation// model, while the Graphiti implementation stores the values as //properties// in the Graphiti //Pictogram// model. If you are developing an editor based on GMF or Graphiti, simply reuse these implementations and you're fine. Otherwise, read this section to learn how to implement a suitable configurator. 276 + 277 +A //mutable// layout configurator is one that can not only read option values, but also write them. Most interface methods are rather self-explanatory, therefore we will consider only the {{code language="none"}}getContextValue(IProperty, LayoutContext){{/code}} method here. This method receives a [[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"]] and should return a value that corresponds to the given property, if possible, and {{code language="none"}}null{{/code}} otherwise. The starting point is usually the current value of {{code language="none"}}LayoutContext.DIAGRAM_PART{{/code}} in the given context, called the //diagram part//, which refers to the currently selected diagram element in the viewer (the abstract syntax element). From this the method should extract more information considering the following other context properties: 278 + 279 +* {{code language="none"}}LayoutContext.DOMAIN_MODEL{{/code}} – The domain model element linked to the current diagram part. 280 +* {{code language="none"}}LayoutContext.CONTAINER_DIAGRAM_PART{{/code}} – The diagram part that corresponds to the graph or subgraph that contains the current diagram part. This is called the //container//. If The current diagram part is already the top-level element of the diagram, then there is no container and {{code language="none"}}null{{/code}} should be returned. 281 +* {{code language="none"}}LayoutContext.CONTAINER_DOMAIN_MODEL{{/code}} – The domain model element linked to the container. 282 +* {{code language="none"}}LayoutContext.OPT_TARGETS{{/code}} – A set containing the kind of graph element that corresponds to the current diagram part, referenced with the enumeration [[LayoutOptionData.Target>>url:http://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"]]. If the diagram part is a node, for example, the set should contain the value {{code language="none"}}NODES{{/code}}. If the node is also a container for a subgraph, the set should additionally contain the value {{code language="none"}}PARENTS{{/code}}. 283 +* {{code language="none"}}DefaultLayoutConfig.HAS_PORTS{{/code}} – If the current diagram part is a node, the returned value for this property should be {{code language="none"}}true{{/code}} or {{code language="none"}}false{{/code}} depending on whether the node has any ports or not. Ports are explicit connection points for edges; they occur frequently in data flow diagrams. 284 +* {{code language="none"}}DefaultLayoutConfig.CONTENT_HINT{{/code}} – If the diagram contains an annotation about which layout algorithm to use for the content of the current diagram part, the returned value for this property should be the identifier of that algorithm. This is the same kind of annotation that is accessed through {{code language="none"}}getOptionValue({{/code}}…{{code language="none"}}){{/code}}, i.e. a value set by the user with the Layout View. 285 +* {{code language="none"}}DefaultLayoutConfig.CONTAINER_HINT{{/code}} – The same as for CONTENT_HINT{{code language="none"}}{{/code}}, but referring to the container. 286 +* {{code language="none"}}EclipseLayoutConfig.EDITING_DOMAIN{{/code}} – If your diagram editor needs an EMF editing domain in order to modify annotations of layout options, then such an editing domain should be returned for this property. 287 + 288 +An instance of your self-made configurator should be returned by the {{code language="none"}}getDiagramConfig(){{/code}} method of your diagram layout manager.
- Confluence.Code.ConfluencePageClass[0]
-
- Id
-
... ... @@ -1,1 +1,1 @@ 1 -94 699971 +7700944 - URL
-
... ... @@ -1,1 +1,1 @@ 1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/94 69997/Configuring Automatic Layout1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/7700944/Configuring Automatic Layout