> On Nov 26, 2015, at 10:47 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Nov 26, 2015, at 18:11 , Alex Hall <mehg...@icloud.com > <mailto:mehg...@icloud.com>> wrote: >> >> Moving Controls in the Outline Table > > Well, that was a scary experience.
I imagine it was. :P > > There’s a lot more going on there than meets the eye (excuse the expression, > but it’s literally true in this case). > > 1. That “invisible button” on the right isn’t an invisible button, it’s > another column in the outline view. It’s empty in most rows, but in a > top-level row (like Window), it actually contains a button that causes the > auto-layout errors to be displayed. (The outline view slides over to the > left, and the auto-layout errors list slides in from the right.) If there are > no auto-layout errors, the button that’s there is invisible, though it still > works. (!) Interesting, and quite useful, I imagine. Sadly, the list of problems appears--at least after a quick test--to be totally invisible to VoiceOver. The table appears not to change at all when the button is pressed. > > The virtue of going to this column, in your instructions, is that it isn’t an > editable outline view cell, so you can’t accidentally start editing text, as > happens if you try using the main column. (The column to the left of the main > column is the disclosure button, of course.) That makes sense. > > 2. What happens when you press the Control key during dragging in an outline > table is that the selected row, which got is selection dimmed when dragging > starts, gets its selection undimmed and you can’t drop. I dunno why. > > 3. What happens when you press the Command key during dragging is — exactly > nothing. > > 4. What happens you press Command *and* Control during dragging — depends on > which outline view it is. In the navigator pane, it works like plain Command > (does nothing). In the object outline, it works like plain Control (disables > dropping). > > Cases 2 through 4 are the behavior using an actual mouse/trackpad. Continuing > on with VO: > > 5. What happens when you unlock the mouse to end the drag, given that you > have Command+Control held down because VO, is the same as #4 (i.e. nothing) > *except* when you drag between scenes, in which case it works. (!) > > VO summary: > > — You can rearrange a regular outline view like the navigator pane. > > — You can’t drag into the IB object outline, except… > > — … in the unique case of VO dragging between scenes, you can. > > Executive summary: > > — You can’t drag an object out of the object library using VO, at least not > by dragging it. That's odd, because it's how I always add controls from the object library to my scenes' views. I'm not sure how else I'd do it, since copying and pasting seems to replace things in my storyboard rather than adding to them. > > I kept the best till last: > > 6. Although VoiceOver Utility is configured to allow Command+Control *or* > Caps Lock as the VO modifier, Caps Lock doesn’t actually do that on my Apple > keyboard. If the light is on, it goes out when VO is enabled, so something > thinks it’s trying, but it doesn’t actually work. If it did, it would solve > all of the above by avoiding the need for Command or Control to always be > down. Just for the record, the VoiceOver keys are control and option. I hope that doesn't confuse the issue too much. :) I'm not sure how the caps lock thing works internally; the control key pauses or resumes speech if pressed by itself, but with caps lock as the VO modifier, caps lock pauses or resumes speech as well. Maybe it's emulating it internally somehow? > > Somebody in Cupertino needs a dope slap, I think. LOL, I think that sometimes as well. Xcode has, believe it or not, gotten much better with version 7. I keep hoping some team at Apple will get assigned to make it work *well* with VoiceOver, but that happy day hasn't come yet. Ideally, VoiceOver's own drag/drop commands would be fully supported (vo-comma and vo-period, hold down for modifier options). Better still, keyboard commands for *everything*. Imagine moving to a control in the object library, hitting a keystroke, and getting a popup menu that mimics the layout of your storyboard. Choose the destination, and your done, still in the object library. Then, to connect an outlet or action, write the stub, find the control in the outline, hit a keystroke, and choose the action/outlet you want. So much in Xcode technically works, but could be made so, so much better still. All the workarounds and oddities I know of so far are in the guide I linked to, but I'm sure there are others. I haven't yet done anything with making an app ready for the App Store, dealing with items in the assets catalog, using a repo, etc. As Cara said, thank you for your time investigating this and writing up your findings. Blind developers are a tiny minority, but we're out there. With better, easier tools, I like to think there would be more of us. If any Apple engineers happen to read this thread, hopefully they now have a clearer idea of what work still needs to be done. >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
