![]() |
Gorgon Game Engine
|
Apart from the top level container, each component should be in container.
Components arrangement in a container first depends on component positioning. If a component is relatively positioned, then it will follow the container orientation to be stacked with the other relatively positioned components.
Components have multiple sizing modes. The first set of options control how the component will be sized in case it contains an image, text, or another component stack. If the size is Fixed, the size of the contents is ignored. Automatic uses the size of the contents. GrowOnly, ShrinkOnly options allow component to grow/shrink if the contents is larger/ smaller than the given size. Sizing can be adjusted separately for X and Y axis. When grow only and shrink only options are combined with relative sizing the size calculation is performed between fixed and always relative size calculation time. Mixing multiple automatic grow/shrink only, relatively sized components in the same container is not recommended. The system will try to fit automatic grow/shrink relatively sized components as best as possible with a single pass. Ex: There are two components, both are 50% in width and one of them is shrink only, container has 100px usable size. If the shrink only component has a content of 40px, the other component will be grown to fill the remaining 60px, even though it will be more than 50%. If this is not desired, shrink only component can be placed inside a 50% sized container, and its relative size should be set 100%.
Component size can also be relative. In this case, container orientation plays an important role. If the relatively sized axis is not in the oriented direction, then the entire usable size of the parent is used for the calculation. However, if the axis is the oriented direction, then only the unused space is considered during the relative size calculation. For instance, in a horizontally oriented container, assume there are two components. One has a fixed width of 50px and the other is set to 100% and the container has 200px usable width. Assuming no additional spacing, second component will have 150px width. This calculation depends on how the components are anchored and margin/padding/ indent/border size.
Size of the component can be influenced by the value channels. In this case, the size of component is used as additional size on top of the relative size depending on the channel value.
It is possible for widgets to specify additional size to tags. In these cases, the given size will be used as an addition to the original size. It is not recommended to use automatic sizing with tags that the widgets can use (e.g., ContentsTag).
In this system 4 spacing methods are used. First method is border size. Border size is excluded from the internal area of a container. Thus (0, 0), does not include the border. In this system, borders are not drawn automatically, they are a part of the background image, therefore, border size is not calculated. It should be supplied.
The second spacing is provided by the padding of the container. Main difference of padding is that it collapses with the margin of the components as well as being counted in the container. If the padding for any edge is negative, it will not be collapsed.
Margins are spacing around the components. Unless negative, they collapse. This means if two components are anchored together, the margin between them is the maximum of the margin their touching edges. Negative margins are always added.
Indent is the last spacing. It is additive and only used if a component is anchored to its parent. This is very useful in repeated or conditional components. For instance, if a button can have icon with text. You may want extra spacing on the text if there is no icon. This can be facilitated using Icon1IsSet condition and indent.
All spacing except for border size can be relative. For padding, the size of the component excluding the borders is used. For margin and indent, size of the parent excluding the borders is used. 50% margin left will effectively start a component from the center. However, anchoring should be used for this case.
All components are placed according to their anchor points. Relatively positioned components can be anchored to another component, but absolutely positioned components are always anchored to their parent. Depending on the orientation, relative anchoring will be done to left/right or top/bottom. It is possible for anchoring to cause artifacts, thus it should be used properly.
Absolute anchoring is simple. It uses parent and anchor point. In this anchoring, the component should be inside the parent. This means, if horizontal part of the anchor point is left, then parent anchor should either be left or center, so that the component will be placed in the parent. Otherwise the component will be placed outside the parent. If an absolutely positioned object is attached to left/top or right/bottom of its parent's center/middle, then the effective size of the container if only include right/bottom or left/top portion of the container. If spacing for both sides are equal, this will cut the usable size by half. This feature makes it easier to deal with center starting components.
Relative anchoring requires previous component anchor dictated by the current component and parent anchor. These target anchor points should match. Following previous example, where anchor point was left, parent anchor should again either be left or center. Assuming orientation is horizontal, previous anchor should be right, anchoring the component to the end of the previous one. In a container, there can be two separate anchor stacks, one starting from left to right and the other starting from right to left. This also works with vertical layouts (top to bottom and bottom to top). This is controlled by the combination of the anchor and previous component anchor. If anchor is specified as right and previous anchor is left (or none and parent anchor is right), then the component will be anchored from the right. If previous anchor is none, component is always anchored to the parent. This may cause components to overlap. Components can only be anchored to their parents or other relative components.
First baseline anchor uses the baseline of the first text line. In the calculations, it is considered top aligned. Last baseline uses the baseline of the last text line. It is considered as bottom alignment. If there is no text, first baseline is calculated from the top, last baseline is calculated from the bottom. Baseline can be specified in template. When it is specified, that value will be used instead of calculated baseline. Last baseline alignments should only be used for textholders.
The position of the component effects its place from the anchor. If anchored by left/top or center/middle x/y position is added to the anchor point. If anchored by right/bottom, x/y position is subtracted.
In AbsoluteSliding positioning the component anchors to its parent. For relative size, entire usable area of the parent is used. If the position is specified as percentage, remaining area after the component is placed is used. Ex: parent width: 100, component width: 50, parent padding: 10, component x position: 50%, margin: 0. In this case, component width and padding is subtracted from parent width, 30px remains. This size is used to calculate percentage position, which is 15px. If an component's size is 100%, percentage base positioning will not have any effect on the position of the component.
Relative positioning is very similar to absolute positioning except the component can be anchored to other components and its percent based metrics uses remaining size of the parent in the oriented direction.
Absolute positioning is classical absolute positioning in many systems. It uses entirety of the parent size to calculate percentage based positioning. In other aspects, it is same with absolute sliding positioning.
PolarAbsolute changes coordinate system to polar coordinates. X axis becomes radius and Y axis becomes angle in degrees. Center is used to calculate transformation point. While calculating center point Absolute positioning is used. If radius is percentage based, the maximum size that will ensure component will stay within the parent will be used. Parent anchor is used to decide how to calculate this length. For instance, if the anchor point is TopCenter, then the max radius calculation assumes angle will change from 180-360. This currently does not take value range into consideration. If desired, em size could also be used for angle, which is set to 45deg. Component is then placed according to its center point. To use PolarAbsolute correctly, you should set center of parent, center of component as well as parent anchor of the component (not self anchor) correctly. Setting parent anchor also adjusts maximum and starting angle so that the both radius 0-100% and angle 0-100% will stay within the container. Angle always works counter clockwise. Angle EM size is not changed by the anchor point, however, it is also affected by the starting point. Also, when percentages or value modification is involved, it is advised to set center point of the component so that it will be within the object. This offset will not be automatically done and will leave portions of the object outside its parent.
Position can be affected by the value modification system. In this case specified position is used as an addition with a percentage based value.
It is possible for widgets to specify additional position for a specific tag. It is recommended to anchor such components to top left and instead of using position to place them, use spacing. Only one tag currently is used for position modification: ContentsTag.