Open Aceeri opened 6 years ago
This looks great, make sure to also keep in mind the width and height of the elements. Personally I think the absolute positioning has limited utility and probably only serves to complicate the code without providing new features.
Also: keep in mind some people are going to want to use floats between 0 and 1 for percentage based positioning, sort of similar to the use of % in CSS
@Xaeroxe That will probably be handled with the Coordinate
struct, which is just an abstraction over pixels and percentile and such.
Positioning
For reference this the current component for position (The documentation is a bit off on them since I rethought it a bit) https://github.com/Aceeri/citrine/blob/master/src/class.rs#L88
UI elements should be able to be positioned relative to the parent depending on a couple rules:
Free
positions tells layouts to ignore this UI element and just positions the UI relative to the parent's top-left coordinates, for example if a parent UI is at 5, 10 and the child is at 2, 3 then the child UI's absolute position will be 7, 13.Relative
positions just move the UI relative to where the layout places it. If the UI just wants the layout to figure it out it should just be aPositionKind::Relative
without any x or y offsets. If the parent UI element has no layout handling this, then it should behave the same asFree
.Absolute
positions ignores both layouts and the parent and just places the UI where it is told to be. Defaults to 0, 0 if the x and y are bothNone
. I'm not entirely sure about this one since the alternative is simply just removing theParent
component and it will be relative to the screen.Layout
Each layout should use its own
Component
and being attached to a UI element, which will then mess with the child entities' positions. The built-inParent-Child
system should handle theFree
/Absolute
variants by default and forRelative
UI elements it should first default the position to aFree
-esque position (no layout) and let the layout systems do the rest.