After spending all of the last 3 days on designing autolayout-based layouts in IB, I’m going to submit some bug reports. First, I want to try to clarify my thoughts about “what’s wrong with autolayout”, and see if I need to revise my thinking:
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. Unfortunately, what we developers think/want/expect is that “automatic” refers to the construction of rules at design time. In fact, it’s far from automatic, in any sense. What confuses our expectations, apart from hope for the impossible, is that IB tries to *pretend* that it can be design-automatic behind the scenes. It can’t. If the *design* process was more manual, I think it’d be a lot easier. 2. I’m amazed to consider how much *better* the autolayout design process is in IB these days (Xcode 7.3). I’m not saying it’s any good — on the contrary, it’s amazingly awful — but it used to be so much *more* awful, hard as that thought is to fathom. That’s what’s amazing. 3. The biggest single bug I run into is when there are errors about constraints that say something like “it should be over here, but it’s actually over there”, but the Update Frames action doesn’t move it over “here”. I’ve noticed one clearly reproducible cause of this. When you use popup-like controls like popup menu buttons or path controls, the current width of the control (based on its design-time value) is almost always wrong, because the value that IB uses is the width of the *previous* design-time value. For example, in a path control whose value is “/“ and which therefore displays a single icon for the root volume, the width might be (say) 45 but be reported as something else. If you change the value to “/Users”, the control now shows two components, but reports its width as 45 instead of (say) 130. If you change it back to “/“, the width is back to 45 but is reported as 130. The only way I could find to fix this is to change it to a different value that produces the same width, such as changing “/Users” to “/users” or “/“ to “//“. I suspect that something similar is going on with text fields that have the wrong width or position, but it’s not as easy to fix these. 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. This made sense in the pre-autolayout days, because moving or resizing elements didn’t imply any change to springs and struts. With autolayout-related design, dragging an object (control, view, etc) is almost always ambiguous, because the object has multiple constraints — explicit or implied, as well as other behaviors such as content hugging and priorities — and merely dragging the object doesn’t indicate which of several incompatible constraint changes you mean. IOW, dragging something almost always does nothing (the thing snaps back) or produces an error. 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. 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), because it initially allows you to *seem* to place a lot of stuff by dragging the stuff. However, as soon as you need to use explicit constraints, you end up with a horrible hodgepodge of implicit and explicit constraints. For example, if you put explicit constraints on a table view, constraints on the cell views are still implicit, because they’re a different editing context. What’s much more annoying is that the contents of a stack view are also a different editing context from the sub-hierarchy containing the stack view, which means a hierarchy with stack views is a mixture of explicit and implicit constraints. On top of that, stack views have constraint behavior that’s specified in the view inspector, not as constraints, which makes them simultaneously more and less confusing. Although stack views are great in other respects, they turn the editing hierarchy into a horrible mess. 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. Related to this is the attempt to display the constraints as editable elements in the IB canvas. The problem is not just the visual clutter this adds, nor the difficulty in selecting the right selectable element amongst all of the selectable elements piled on top of each other, but that in many cases the constraints are so occluded that you can’t see *any* of them, except for a few meaningless mouse droppings around the edges. If there’s any value in displaying them in the canvas, it’s negated if you can’t *see* them. 7. The conclusion I think I’ve talked myself into is that there’s nothing in IB’s WYSIWYG *object* editing that works well enough to be worth preserving. I think I’d prefer it to be thrown away and replaced by a usable *constraint* editor, where the constraints are the entities directly edited with the mouse, and the objects being configured through inspectors. In other words, turn the current system on its head. _______________________________________________ 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
