Skip to content

Conversation

@alyakan
Copy link
Contributor

@alyakan alyakan commented Feb 26, 2018

PR addresses issue: #209

Additions respect counter clockwise ordering of constraints

When you set the excluded edge to .right or .left, you would expect that the opposite would be pinned and not .leading or .trailing.
@alyakan alyakan force-pushed the fix/issue-#209-autoPinEdge-RTL branch from 91192c7 to fd3ee4f Compare February 26, 2018 19:31
@toohotz toohotz self-requested a review February 26, 2018 19:56
Copy link
Member

@toohotz toohotz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there, it would be nice as well if you could also do the same for the -[autoPinEdgesToSuperviewMarginsExcludingEdge] since it follows the same principal in regards to the edge differentiation

@alyakan
Copy link
Contributor Author

alyakan commented Feb 27, 2018

@toohotz Done 👍

if (edge != ALEdgeTop) {
[constraints addObject:[self autoPinEdgeToSuperviewEdge:ALEdgeTop withInset:insets.top]];
}
if (edge != ALEdgeLeading && edge != ALEdgeLeft) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You seemed to have reversed the edges here? Ie. ALEdgeTrailing going to ALEdgeLeading? Same goes for the ALEdgeRight and ALEdgeLeft.

Copy link
Contributor Author

@alyakan alyakan Feb 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the != to ==. So before, it was if the excluded edge is not leading, then pin to leading, now it is if the excluded edge is trailing, pin to leading. I changed it to == to make sure we're using either leading/trailing or right/left @toohotz

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alyakan I follow now, it just seems a bit odd going from the non equality to equality and also the constraints originally are being added in a counterclockwise manner vs your changes now being clockwise so if I were used to making a reference to the second constraint out of the four that is returned before these changes, I would now end up with the opposite side constraint here. @tomidelucca @mickeyreiss @jjksam maybe you guys want to chime in here with your thoughts?

Copy link
Contributor Author

@alyakan alyakan Mar 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if i'm wrong, but I believe that I still do follow the counter clockwise manner where I go by adding:

  1. Top (if excluded edge is not top)
  2. Leading/Left (if excluded edge is trailing/right)
  3. Bottom (if excluded edge is not bottom)
  4. Trailing/Right (if excluded edge is leading/left)

As for why I went to equality instead of inequality, it's just to simplify the if conditions because otherwise it would have been nested:

if (edge != ALEdgeLeading) {
    if (edge == ALEdgeRight) {
        // Add left edge
    } else {
       // Add leading edge
    }
}

@toohotz

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake, I was reading the conditionals with the assumption of the old code logic, makes sense now and avoiding the nested conditionals as well. 👍🏾

if (edge != ALEdgeTop) {
[constraints addObject:[self autoPinEdgeToSuperviewMargin:ALEdgeTop]];
}
if (edge != ALEdgeLeading && edge != ALEdgeLeft) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise here I believe you accidentally swapped their places as well.

@tomidelucca
Copy link
Member

tomidelucca commented Mar 3, 2018

Unit tests are failing in macOS. Margin related methods are only allowed in iOS. Can you fix them? The CI's log has relevant info!

@toohotz
Copy link
Member

toohotz commented Mar 5, 2018

@alyakan I merged in my PR for the margins so you can pull in my changes and tuck your test methods underneath mine inside of the #if PL__PureLayout_MinBaseSDK_iOS_8_0 checks that I have and you should be good to go. 👍🏾

@alyakan
Copy link
Contributor Author

alyakan commented Mar 7, 2018

@tomidelucca Everything is good to go 👍

@toohotz toohotz merged commit d57ee9c into PureLayout:master Mar 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants