Re: Thoughts on autolayout
Re: Thoughts on autolayout
- Subject: Re: Thoughts on autolayout
- From: Jonathan Mitchell <email@hidden>
- Date: Thu, 21 Apr 2016 09:50:32 +0100
> On 21 Apr 2016, at 08:12, Quincey Morris <email@hidden> wrote:
>
> 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 quite the same but Xcode used to have an option, I forget the terminology used in the IB menu, to exercise a view’s/window’s constraints within the edit as the view.window was resized. So you could resize the view/window and check that AL was playing along as you had hoped. I agree that a more dynamic editor would be a huge boon.
>
> 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.
The implicit constraint assassin is a continual source of problems. At least with the constraint UI editor in Xcode we can at least get some insight into what constraints actually turn up to the layout party
> 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.
I agree that stack views are supremely useful however they are a usability mess from a development point of view in IB.
Personally I have a subclassed NSStackView and construct all of my view hierarchies in code.
The biggest single issue I have with AL is that it is a development time hog.
WPF layout is way more straightforward - I have ported a complex WPF app to OS X and the effort I have had to put into AL is substantial.
I think that a XAML like approach provides a more modern approach to UI layout that what is currently offered by IB.
Why can’y we have a modern public extensible XIB format that can be edited directly or via an IB like tool?
I am not sure just how AL constraints could be easily expressed in such an approach but the new anchor API’s might help out a lot.
J
_______________________________________________
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