I am working on a small game for Apple TV, and one thing I can't get to work is moving the focus from one button to the other (programmatically), or temporarily remove focus from any object (buttons) as the game is doing stuff.
I've seen the guide about objects and focus, but is there really no way to programmatically move the focus to an other part of the screen as the input is needed there (instead of letting the user move all the way across the screen)?
There will always be a view that has focus. It's not possible to not have a focused view.
You could temporarily change the focused appearance of an item, so it doesn't appear to have focus, but that would likely be be confusing for the user, or conflict with Human Interface Guidelines.
There's no explicit way to programmatically move focus from one control to another, per the App Programming Guide for tvOS:
The Focus Engine Controls Focus
Only the focus engine can explicitly update focus, meaning there is no API for directly setting the focused view or moving focus in a certain direction. ...
The focus engine controls focus to make sure that it does not move around the screen unexpectedly, and that it behaves similarly across different applications.
Answers to other questions have suggested that you could "game" the system by overriding preferredFocusedView, conditionally setting it to the desired control to move to, then requesting a focus update. Such an approach would likely be fragile.
Related
I have a wide "dock" area at the bottom of the screen. I have placed a UIFocusGuide across the top of it. Depending on which element in the dock has focus, the system may or may not have a focus solution if the user swipes up.
How can I tell my focus guide to use the system-calculated new focus item if there is one, but if not, it should use the one configured in my setPreferredFocusEnvironments:
Alternatively, is there a way to determine where a "swipe up" will take the focus without actually doing it? As the focused element in the dock changes, I could check this and if it has no destination provided by the system, I can add one.
My dock is a view within a main view controller but preferredFocusEnvironments is never called when the user tries to move to a non-existent view from an element in the dock.
I have a UWP/xaml application. I use AutoSuggestBox on many screens, often several of them on a screen.
I have a problem where the suggestions for one or more of these controls pop open at unwanted times, usually when a screen first renders. Nobody has clicked or tapped on the control. Furthermore, it appears to be in a weird state in which the suggestion list seems to be floating above the window containing the control, often extending outside of that window.
The problem is not consistent. I've identified a few paths that make it happen frequently, but there doesn't seem to be any explanation as to why it is happening sometimes on some controls but not others.
Frank
I have a form in my Cocoa app that contains an NSSegmentedControl that I want to be controllable via the keyboard. It seems that NSSegmentedControl is very reluctant to become the first responder, however.
Setting the initial first responder of the window to the segmented control does nothing -- it will not have keyboard focus when the window is first loaded. It does receive focus if I manually set the first responder like this, however:
[segmentedControl.window makeFirstResponder: segmentedControl];
That will work fine if the only part of the form is the segmented control. If I add another field (say, an NSTextField), and I set the nextResponder of the segmented control to that field, the segmented control will never become first responder. Focus will immediately go to the text field, and pressing tab to switch back to the segmented control doesn't work.
I've tried subclassing NSSegmentedControl and overriding acceptsFirstResponder, becomeFirstResponder, etc. to no avail. The only one that makes any difference is resignFirstResponder -- if I return NO from that method then the segmented control will indeed retain focus, but obviously I don't want it to retain focus all the time.
Any ideas on how to get the control to behave like a normal responder?
It's behaving as intended. Not all controls participate in the "key view loop". Full keyboard navigation is turned on through Universal Access in System Preferences for all apps and it's not for individual apps to implement on their own.
It's best not to use a segmented control in a form intended for heavy keyboard entry. NSPopUpButton works more closely to what we all exepect in a web form so it's not as if it's necessarily the wrong choice in your app's UI.
Rather than answer exactly the question you asked (which someone else can do), I humbly suggest you choose on the side of functionality at the cost of a slightly prettier UI element since that prettier UI element wasn't intended to get along with the keyboard.
In my app, I have a view that cycles through a number of images. Non-VoiceOver users are able to swipe over the view in order to move backward or forward in the list of images. I've used the UIAccessibilityContainer protocol to properly fill this with accessibility elements so that VoiceOver users are able to "hear" all the items in this set by going through them with the one-finger next/previous item gestures.
What I can't figure out is how to update the image in the UI based on these events. Now, I realize VoiceOver is geared towards blind users and it's probably not a huge deal if the UI doesn't update, but some VoiceOver users are only partly blind, and it's a point of performing the correct behavior regardless.
Is there a way to tell when the user has selected a different element in an accessibility container so that I can update the UI accordingly?
Could the UIAccessibilityFocus Protocol be what you're looking for? Specifically accessibilityElementDidBecomeFocused? I would guess each element in your container should get this called when VoiceOver moves focus to them.
is it possible to have a sheet that pops out of a view? For example, I'd like to make it pop out of a bottom view in a NSSplitView.
I'm aware of popovers on Lion, but I need sheets since they are modal, they are available before Lion, and they are harder to dismiss.
AFAIK it's not possible and also not in line with Apple's UI guidelines. Obviously you could try to roll your own but that would involve a considerable amount of work.
EDIT: Actually, I think rolling your own is also difficult. The tools at hand are either a view or a window. I think you cannot use a view as views cannot draw themselves outside the frame of a window - unless you can somehow restrain your dialog within the bounds of the window that shows them. You would then need to setup the animation that shows the rolling sheet from your NSSplitView.
Windows are then the other alternative. To have them behave like modal sheets, you would want them borderless and by design they then cannot become a key window. So, the user would need to explicitly click the sheet to get focus which defies the purpose of a modal sheet in my opinion.
Both ways, a challenge...