Re: Storyboard, magnification and Xcode 4.x usability.
Re: Storyboard, magnification and Xcode 4.x usability.
- Subject: Re: Storyboard, magnification and Xcode 4.x usability.
- From: Kevin Cathey <email@hidden>
- Date: Thu, 16 Aug 2012 07:46:39 -0700
> Along these lines, there is this other menu item in the Editor: Canvas: menu called "Live Autoresizing", but searching the help and docs that come with Xcode, an explanation of what this does is nowhere to be found.
Live Autoresizing controls whether or not the autoresizing mask for a view should be applied when resizing. For example, if you put a button in a view, and set the button's autoresizing mask to be pinned to the right strut, if "Live Autoresizing" is checked, when you resize the view, the button will stay pinned to the right. But if "Live Autoresizing" isn't checked, it will not stay pinned to the right when resizing the view. You can hold Command when starting a resize which will flip the state of this.
If you are working with a document that uses auto layout, then "Live Autoresizing" is hidden, and instead you get "Apply Constraints to Descendants" and "Apply Constraints to Ancestors/Siblings", both toggle able entities. Let's return to the case of the button pinned to the right of a view (only this time it's using constraints, not autoresizing mask). If you are applying constraints to descendants, then if you resize the view, it will keep the button pinned to the right when resizing. If you don't apply to descendants, it will break the constraint to the button when resizing, and button will stay where it is. Let's say now that you have two buttons next to each other separated by a spacing constraint. If you are applying constraints to ancestors/siblings, when you resizing one of the edges of the buttons, it will keep the spacing constraint intact and actual push the button out of the way as you are resizing. If you aren't applying constraints to ancestors/siblings, then it will break the spacing constraint, for example. As with "Live Autoresizing", holding command when starting the resize toggles the bits for both of these axises of resizing.
> It's a real surprise to find Interface Builder menu items hidden in the nondescript Editor menu
Many of the controls in the Editor menu as also in a black lozenge in the bottom of the canvas, such as the ability to zoom in and out.
Kevin
On Aug 15, 2012, at 1:57 PM, Alex Zavatone <email@hidden> wrote:
> In Xcode 4.2, I just discovered that the menu items to control the magnification/zoom level of the Storyboard are no where near the View menu where I expected them to exist, if they existed anywhere at all.
>
> Much to my surprise, they actually exist in this menu:
> Editor: Canvas: Zoom: Zoom In
> Editor: Canvas: Zoom: Zoom Out
>
> Going through the docs on the IB, I didn't find any information that these actually existed at all, but checking the key bindings preferences showed that they existed and could be mapped.
>
> Along these lines, there is this other menu item in the Editor: Canvas: menu called "Live Autoresizing", but searching the help and docs that come with Xcode, an explanation of what this does is nowhere to be found.
>
> Does anyone know what this does?
>
> On a related note, this might have been fixed in later versions of Xcode, but in the same menu, there is "Show Document Outline" item, which is a toggle between show and hide the document outline. This menu item either should have a checkbox next to it or change from "Show Menu Item" to "Hide Menu Item", as that is what it does.
>
> It's a real surprise to find Interface Builder menu items hidden in the nondescript Editor menu. Back in the pre MX Director days, when we had a new window move to the front that contained functionality that needed specific menu items, we put up a menu that was specific to that functional area. It actually had the name of the functional area. When the window left the foreground, it went away. This removed all confusion of where to find menu items that only applied to that functional area.
>
> "Editor" seems like a strange place to be the catch all for window specific items, especially items that are related to the zoom level of a view, when there already is a view menu.
>
> It would seem to make a lot of sense if we are to use Editor as the menu for window specific items, that it actually change its name to the functional area it represents.
>
> Just a thought.
>
> Somehow, Xcode 3.1.3 was a massively more intuitive to use and figure out than Xcode 4.x. Even when searching the documentation. Hopefully, this can improve.
>
> Cheers,
> - Alex Zavatone
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden