Thanks, Quincy. That’s reassuring! I will trust I’m doing the right thing.
-Laurent.
--
Laurent Daudelin
laur...@nemesys-soft.com <mailto:laur...@nemesys-soft.com>
Skype: LaurentDaudelin
iMessage – WhatsApp – Viber – Line
Logiciels Némésys Software
http://www.nemesys-soft.com/ <http://www.nemesys-soft.com/>
> On Sep 26, 2019, at 23:35, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Sep 26, 2019, at 10:55 , Laurent Daudelin <laur...@nemesys-soft.com
> <mailto:laur...@nemesys-soft.com>> wrote:
>>
>> I’m pretty much in the same situation. There seems to be something going on
>> behind the scene. I also observed that when I started adding constraints, I
>> would suddenly get many warnings and errors, some alluding to missing “y"
>> location where I can clearly see one constraint addressing that “y” location.
>
> What you say sounds correct to me:
>
> Richard’s description *is* the old behavior, just with a slightly different
> UI. The root view cannot be constrained via auto-layout relative to its
> ancestor, because by definition it occupies the entire geometry defined by
> its view or window controller. I assume it’s set to “Translates autoresizing
> mask into constraints” to *prevent* you from adding constraints, not because
> its autoresizing mask is *actually* translated into constraints (although I
> guess it may be so, as some internal implementation detail).
>
> Subviews, in the past, had the automatic behavior (except for special cases
> like views inside scroll views). If you didn’t add any constraints, the IB
> inspector showed the autoresize mask UI with the springs and struts
> behaviors. As soon as you added any auto-layout constraints, that went away
> and the frame was completely controlled by auto-layout.
>
> The problem with multiple warning and errors when you start adding
> constraints has been around for a while. Xcode is just bad at knowing when
> the view is properly constrained, although I’m prepared to concede that there
> are cases where it correctly complaining, even though the constraints *look*
> complete to our meager human brains.
>
> On top of that, Xcode is really lousy at diagnosing real layout issues at the
> right level of the view hierarchy. It (pre-Xcode 11, I haven’t played with
> the new version yet) would be unable to confirm that a view was properly
> constrained if a subview wasn’t properly constrained, but would complain
> about the parent view, not the subview.
>
> On top of *that*, Xcode was incredibly bad at adding missing constraints. It
> would often add constraints that didn’t actually fix the problem, leading to
> other errors, or fail to add the constraints it said was going to add.
>
> But there’s more! Xcode would *also* fail to re-evaluate constraints properly
> *even after you or it fixed the problems by adding the right constraints*.
> The error messages would often continue to be displayed, but if you quit
> Xcode and started it again with the same project open, the errors would no
> longer be there. (!)
>
> As I said, I haven’t had a chance to find out whether Xcode 11 is any better
> at all of this. The only advice I can give is to be persistent, to be
> thorough, and to think outside the box (literally).
_______________________________________________
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
