-
Notifications
You must be signed in to change notification settings - Fork 111
RBLView and requiresConstraintBasedLayout default setting #44
Comments
I would be fine with changing the default, since it was implemented before we ran into some of our own troubles with Auto Layout as well. It'd be nice to have a consistent subview layout hook on 10.7 and 10.8, though. I've done this with |
Lets lay out what I think is happening here: On OS X 10.8:
On OS X 10.7:
Not sure where to go from here. We could do an #ifdef and enable the |
At this point, the only thing that occurs to me is an overridable method named That's sucky and confusing, though, and makes me think this responsibility should just lie on the user of the class. |
I'm just desperately thinking of ways we could get rid of the enabling of constraints as that causes no end of problems. |
Agree here, constraints cause a whole host of problems. Literally no existing code works with constraints layout enabled without some serious tweaking. I think either @jwilling's conditional or just diverting the layout responsibilities from |
@jwilling I wasn't disagreeing with changing the default return value of that method. I just think there's no way we can compensate for it elsewhere given the shitty layout APIs. So, let's just remove any default layout code from |
👍 |
I disagree with the default setting of returning YES from
requiresConstraintBasedLayout
.The method
layout
is called only under auto layout on 10.7, whereas on 10.8layout
is called either because auto layout is enabled, or because the view is layer-backed. As a result, apps that need to uselayout
-based drawing code on 10.8 yet still don't want to use auto layout are left in a bind if they want to useRBLView
.If one single view touches any part of auto layout, the whole window will fall victim to the lag that auto layout can induce, especially on table views.
What can be done about this?
The text was updated successfully, but these errors were encountered: