> On 21 Apr 2016, at 12:12 am, Quincey Morris > <quinceymor...@rivergatesoftware.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
