> On 21 Apr 2016, at 08:12, Quincey Morris > <quinceymor...@rivergatesoftware.com> 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 (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
