[under construction] Below is an attempt to apply, consolidate, and standardize GUI coordinate notation systems I have seen in the wild. I'll jump right into examples instead giving lists. "Z" coordinate will not be addressed here for simplicity. "NE;S" - Widget "floats" to north-east (NE) corner of container. If there is already another widget there, then it floats to the south (S) of that existing widget. Thus, the first coordinate specifies the position relative to the '''center of''' the container, and the second the position relative to, but '''adjacent to''', any other widget already there. The second segment thus specifies a "scoot direction" if a widget is already there. The second segment is ignored if there is no conflict. If the second segment ("conflict segment") is not specified, such as just "SW", then "E" is assumed (to the right). This matches typical GUI convention. If "L" is specified, then the widget overlaps when there's a conflict. (The letter "O" is not used because it's often confused with zero.) The Z coordinate (not discussed) would then determine which is on top. ("L" is useful for semi-transparent effects). If there is no room in the container to fit the conflict segment's request and container scrolling is not enabled or not auto-trigger-able, then the following relative relationships are attempted in this order until a spot is found: E (east), S (south), W (west), N (north). If there is still no room after trying these, then an error is thrown. "100%,0%;S" - Same result as above ("NE;S"). This uses and '''X/Y percent-based''' coordinates, per upper-left being 0%,0%. Here are some sample with equivalencies: * N = 50%,0% * S = 50%,100% * W = 0%,50% * SE = 100%,100% * NW = 0%,0% 50%,50% - Midpoint of container. Unlike the compass notation, percent notation can target the center areas directly. For the "conflict" segment, the part after the semi-colon, if percent-based coordinates are used, then it's essentially a vector pointing the direction of the shift. "50%,50%" wouldn't mean anything useful and would be ignored, meaning "E" (the default) is implied. Because a percent-based conflict segment could be confusing, it's recommended one usually use the compass version for all conflict segments. The only exception would be if you wanted an "oblique" stacking angle that's not a clean multiple of 45 degrees, such as say 177 degrees [1]. If we wanted to "stack" widgets diagonally from top-left to bottom-right, we could use a '''series of''' "NW;SE". Each widget would "try to be" in the upper-left corner (NW), but if there is already a widget there (which we expect after the first one), then "SE" tells it to "scoot" south-east until it finds room. Remember, "SE" is not where the widget tries to go relative to its container, but rather relative to any widget in its way. The second widget thus would ''not'' end up at the bottom right (unless the container was really small). The equivalent percent notation would be "0%,0%;100%,100%". 1 . . . (Only 3 shown, where the number indicates the order specified.) . 2 . . . . 3 . . . . . If we wanted to make a tower of widgets that stacks vertically like child blocks, starting at the bottom center, then a series of "S;N" would do the job. . . . . . . . 3 . . . . 2 . . . . 1 . . --top ------------ Footnotes [1] It may be misleading to use 45 degree increments as a reference angle because with non-square containers the aspect ratio "stretches out" the usual directions. Suffice to say, the percent approach gives one more scoot-direction options than the compass convention. Also, we could use this system for non-rectangular areas, such as polygons with say 42 points (non-crossing), if a rectangular "guidance" container is assumed to be around the polygon. Any "edges" inside the rectangular area are treated like an existing widget(s) and the usual "conflict scooting" rules applied.