Re: Thoughts on autolayout
Re: Thoughts on autolayout
- Subject: Re: Thoughts on autolayout
- From: Kristof Van Landschoot <email@hidden>
- Date: Thu, 21 Apr 2016 10:36:35 +0200
All of these points sound more like "Thoughts on Interface Builder to me".
Using autolayout without Interface Builder is a better experience (although
not perfect, surely).
On Thu, Apr 21, 2016 at 9:12 AM, Quincey Morris <
email@hidden> wrote:
> 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 (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
_______________________________________________
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