Re: Thoughts on autolayout
Re: Thoughts on autolayout
- Subject: Re: Thoughts on autolayout
- From: Ben Kennedy <email@hidden>
- Date: Thu, 21 Apr 2016 10:47:53 -0700
> On 21 Apr 2016, at 12:12 am, Quincey Morris <email@hidden> wrote:
> 1. Part of the problem is branding. “Autolayout” actually refers to the runtime layout engine, and what happens automatically is the runtime relocation of UI elements according to constraints.
Yeah, the more descriptive term is “constraint-based layout”. Apple seems to use both. From the perspective of the developer, the latter makes more sense.
> 4. The biggest single autolayout-related design flaw in IB is its pathetic deathgrip on the concept of WYSIWYG editing by dragging UI elements around.
It's interesting you say this; when preparing a constraint-based layout, that type of workflow has rarely ever occurred to me. I usually visualize what I want to achieve, then create constraints as necessary (typically by selecting a view, then clicking one of those little pop-up menu things in the lower right to spawn the popover). As such I'm not sure I appreciate the "death grip" you're alluding to.
> I think I’d much rather have a scheme where you can’t drag or resize UI elements at all, but you would essentially drag on the constraints (or on attributes that uniquely represent constraints that can be consistently altered by dragging) instead.
Not a bad idea; locking the views themselves in place against direct (and functionally fruitless) dragging might help combat some of the feeling that the UI is drenched in too much lubricant.
> 5. The second-biggest autolayout-related design flaw is the idea that IB provides invisible default constraints for any object that doesn’t have any explicit constraints. This is a consequence of the drag-it-till-it-hurts problem (#4),
I think this is actually a consequence of translatesAutoresizingMaskIntoConstraints being set to YES in the absence of any constraints; as such, the view gets explicit canvas-based positioning. At least, this appears to be the case a lot of the time. I would argue this is a UI problem in IB where it tries to smooth over the transition between autoresizing- and constraint-based layout without properly informing the user.
> 6. The third-biggest problem is that there are two separate inspector-based editing interfaces for constraints, and they’re on different tabs of the Utilities panel. If you select a UI element, you need the Size tab, but if you select a constraint, you need the Attributes tab. On top of that is the problem, generally, that the Size and Attributes each contain settings that are intimately related to the other. These two tabs desperately need to be merged (back) into a single tab.
This is frustrating as hell, and I couldn't agree more.
What's equally infuriating is that it seems damn near impossible to delete a constraint from those tabs. Pressing backspace (or "delete" as Apple's keyboards call it) merely *disables* the constraint. One is then left to hunt around in the damn list on the right in order to find it and then delete it *again* from there in order to actually eviscerate it.
b
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden