I’ve never had to do anything like step 4. I’ve certainly added or changed constraints and fetched up a load of red boxes but never does it take more than a little bit of consideration to work out which constraints to remove or change.
Basically - it just isn’t that hard. > On 22 Apr 2016, at 17:09, Stephane Sudre <dev.iceb...@gmail.com> wrote: > > I tend to believe that it's because of step 4 that some developers > (#include me) still do not like auto layout. Because even with a very > simple view, you can waste a lot of time with this step. > > On Thu, Apr 21, 2016 at 9:49 PM, Bill Cheeseman <wjcheese...@gmail.com> wrote: >> >>> On Apr 21, 2016, at 3:19 PM, Charles Srstka <cocoa...@charlessoft.com> >>> wrote: >>> >>> Am I the only one who likes autolayout? >> >> >> No, I like it, too. I developed an approach that I'm comfortable with, and >> if I stick to it I can get the job done quickly. Of course, trying to >> accomplish something I haven't done before requires a little more thought, >> but I find that I can figure it out pretty quickly. It almost comes natural >> now. >> >> I use IB exclusively. My approach goes like this, on a one-window-at-a-time >> or one-view-at-a-time basis: >> >> 1. Drag all the views and controls onto the canvas and drop them more or >> less where I want them to end up. Don't waste any time trying to align them >> or make them the right size exactly -- just get position and size >> approximately right and move on. Leave it looking a little ragged. Above >> all, don't create any constraints yet. >> >> 2. Write enough of the application code to get a sense whether the layout >> needs to be changed. Change it as needed, but again don't waste any time >> getting it exactly right and don't create any constraints yet. >> >> 3. When the design feels like its ready to be frozen, create the >> constraints. DO NOT move the controls and views into the exact place they >> belong and then add constraints -- instead, do it the other way around: >> create the constraints first and then tell the controls and views to obey >> them. It will be much easier to see that they all moved into the right >> place, because they will all move a relatively short distance. More on this >> step below. >> >> 4. Every time you tell a window or view to obey new constraints, watch very >> carefully. If the controls and views move or resize in unexpected ways, or >> disappear completely, immediately choose undo to get back to where you were >> (with all the controls and views in approximately the right locations). Then >> figure out which constraint you left out or got wrong, and fix it. >> Repeatedly undo and fix as needed. >> >> 5. When you think you're done, lock the constraints down and do a lot of >> window resizing, divider dragging, and so on to test them. >> >> More on step 3. I create constraints the way I read: start at the top left >> corner, move item by item to the right, then move down one "row" and start >> at the left again, and so on until I reach the bottom right corner. This >> leads to some useful consistencies to help my brain figure out why something >> went wrong. (a) For example, it is often only the leftmost button in the top >> "row" of controls that needs a top constraint to the superview; the other >> buttons in that "row" will have their vertical dimension controlled by >> baseline or center alignment, or something similar. (b) Horizontal >> constraints are easily made complete, because I account for each piece one >> step at a time from left to right: leading constraint, width constraint, >> trailing constraint, etc. (c) I don't worry about hugging priorities and the >> like until all else fails, because the default priorities are designed to be >> right for most situations. >> >> -- >> >> Bill Cheeseman - wjcheese...@comcast.net >> >> _______________________________________________ >> >> 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/dev.iceberg%40gmail.com >> >> This email sent to dev.iceb...@gmail.com > > > > -- > Packaging Resources - http://s.sudre.free.fr/Packaging.html > > _______________________________________________ > > 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/rols%40rols.org > > This email sent to r...@rols.org _______________________________________________ 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
