You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@frozendevil recently pointed out an issue with the way alignment works when using scroll views. Specifically, imagine you have a content view inside a scroll view, with a layout like this:
This will only work correctly when the scroll view has a content offset of zero.
I think we can fix this as part of the move to aligning via bounds and center (#49). Specifically, the alignment methods should treat the receiver view and the other view (the parameter) differently. The view being aligned (the receiver) should be aligned by the rect made from its bounds.size, center, and layer.anchorPoint to the rect of the target view (the parameter) by the rect made from its bounds.size, bounds.origin, center, and layer.anchorPoint.
The text was updated successfully, but these errors were encountered:
One consideration here is that UIView.point(at:) becomes ambiguous with this changes. I think the best option for this is to change the name back to point(inBoundsAt:) to make it clear which rect it's using. I don't think we need to add a method for the other rect, but we can considering adding it in the future if needed.
Thinking more about this, it's a bit more complicated than including the target view's bounds.origin in the alignment computation. Imagine the following view hierarchy:
If we aligned the content view to the scroll view, we'd want to use it's bounds.origin. Same thing with the label. But if we aligned the tooltip to the scroll view, we wouldn't want the bounds.origin. There are also some other weird edge cases, like what happens if we align the scroll view to the content view?
I think the best approach here is to make the behavior explicit in the API. Something like this might work:
enumTargetAlignmentBehavior{/// Align to the position in the target view's frame. This is most commonly used when aligning sibling/// views in a hierarchy.case untransformedFrame
/// Align to the position in the target view's untransformed bounds. This is most commonly used when/// aligning a view to a view in its superview chain.case untransformedBounds
/// Align views based on their relationship in the view hierarchy. If the target view is in the/// superview chain of the view being aligned, this will align to the target view's untransformed/// bounds. Otherwise it will align to the target view's untransformed frame.case automatic
}
@frozendevil recently pointed out an issue with the way alignment works when using scroll views. Specifically, imagine you have a content view inside a scroll view, with a layout like this:
This will only work correctly when the scroll view has a content offset of zero.
I think we can fix this as part of the move to aligning via
bounds
andcenter
(#49). Specifically, the alignment methods should treat the receiver view and the other view (the parameter) differently. The view being aligned (the receiver) should be aligned by the rect made from itsbounds.size
,center
, andlayer.anchorPoint
to the rect of the target view (the parameter) by the rect made from itsbounds.size
,bounds.origin
,center
, andlayer.anchorPoint
.The text was updated successfully, but these errors were encountered: