As you can imagine, being able to apply templates based on conditions is very powerful. The stategroup above checks the visibility of a couple of other frames to change the state and apply the correct template.
You can set a couple of properties directly with it, too, but which actions and conditions exist is unknown to me. I only know the ones that Blizzard uses in their UIs in SC2 and Heroes.
Animations are for direct responses to events, for example in the following snippet, a frame checks if the unit in the current scope has a special behavior. Its state causes a frame to become visible/hidden. That frame's visibility is used above in the state group.
Yes, there is a problem with that. Changing the positioning is unnecessarily more convoluted than it should be. Right now the icons are anchored to the bottom-right of the container. If I wanted them above the unit portrait, I'd have to change the anchoring of the container and the icon template. Also, it interferes with being able to click on other frames in the UI editor.
You only have to change the anchoring of your container.
And what if I later decide to add/rearrange/remove things? Then I have to find and update every other frame that was anchoring to some arbitrary child instead of the container when that was really the intent.
I don't understand the problem. My organization would be like this:
1. Child elements inside the container are collapsible, their height and width are. The child elements are positioned in a row next to each other in the bottom right of their container frame. Their anchors are bound to another, e.g. bottom anchor of the first child and right anchor bound to predecessor child.
To describe the content of each slot, you can create and apply templates as every slot's label and images are created in the same way.
2. The container is anchored with its left anchor to the last child element slot. The bottom right anchors are bound to wherever you want the child elements to appear. If you want the top border to be set correctly, you can use animations for each frame in UI or a state group in UI or set the height in trigger code. But you would only need to do that if you really require the height to be 0 when there are no slots visible.
3. Other frames anchor to the container and are always closely positioned to the space requirements of that container (except for the height unless you add that in one of the 3 ways described above).
4. Triggers hook up each slot's frame, the label and the icon image and edit visibility, text and the image file.
2013 is when the UI stuff was new and I learned everything. Nowadays I am most likely the person outside Blizzard that knows most about UI editing in SC2/Heroes of the Storm. For example, only a couple of people know about the new UI feature of animations and state groups (but to use these features you need to abandon the SC2 editor for UI editing).
So, trying to make me understand your problems is a good way of getting my input. Currently, I am struggling a bit understanding what exactly the problem is as most likely you come with other UI concepts that I do not know.
I understand that. The part that I don't understand is how to apply this to frames containing many different frames, especially frames that aren't tooltips. E.g. I want to wrap up those two number icons (each one made up of a background image, an image and a label) in a container that could then be positioned anywhere easily. Right now I have the container stretching up all the way to $parent (FullscreenUpperContainer) except for the bottom, which is anchored to the top of the command card, because I can't make it only as tall and wide as it needs to be (without hard-coding values).
The container is not visible, so its size can be pretty much the entire screen. There is no problem with that.
But, if you really want to, you can set an anchor to a child frame via just using the child frame's name in the anchor's relative="ChildFrame". If you position your last upgrade icon slot properly, you can just use its top border (= "Min").
State groups are a construct for logic. They resemble a series of IF-THEN statements.
For example, here is the one I use to change mana bar colors in Heroes of the Storm's observer UI:
As you can imagine, being able to apply templates based on conditions is very powerful. The stategroup above checks the visibility of a couple of other frames to change the state and apply the correct template.
You can set a couple of properties directly with it, too, but which actions and conditions exist is unknown to me. I only know the ones that Blizzard uses in their UIs in SC2 and Heroes.
Animations are for direct responses to events, for example in the following snippet, a frame checks if the unit in the current scope has a special behavior. Its state causes a frame to become visible/hidden. That frame's visibility is used above in the state group.
You only have to change the anchoring of your container.
I don't understand the problem. My organization would be like this:
1. Child elements inside the container are collapsible, their height and width are. The child elements are positioned in a row next to each other in the bottom right of their container frame. Their anchors are bound to another, e.g. bottom anchor of the first child and right anchor bound to predecessor child.
To describe the content of each slot, you can create and apply templates as every slot's label and images are created in the same way.
2. The container is anchored with its left anchor to the last child element slot. The bottom right anchors are bound to wherever you want the child elements to appear. If you want the top border to be set correctly, you can use animations for each frame in UI or a state group in UI or set the height in trigger code. But you would only need to do that if you really require the height to be 0 when there are no slots visible.
3. Other frames anchor to the container and are always closely positioned to the space requirements of that container (except for the height unless you add that in one of the 3 ways described above).
4. Triggers hook up each slot's frame, the label and the icon image and edit visibility, text and the image file.
2013 is when the UI stuff was new and I learned everything. Nowadays I am most likely the person outside Blizzard that knows most about UI editing in SC2/Heroes of the Storm. For example, only a couple of people know about the new UI feature of animations and state groups (but to use these features you need to abandon the SC2 editor for UI editing).
So, trying to make me understand your problems is a good way of getting my input. Currently, I am struggling a bit understanding what exactly the problem is as most likely you come with other UI concepts that I do not know.
The container is not visible, so its size can be pretty much the entire screen. There is no problem with that.
But, if you really want to, you can set an anchor to a child frame via just using the child frame's name in the anchor's relative="ChildFrame". If you position your last upgrade icon slot properly, you can just use its top border (= "Min").
@temhawk: Go
<CollapseLayout val="true"/> causes a frame's width and height properties to become 0 while the frame's visibility is false.