I’ve tried to add another attachment that shows this in Space Quest 2. I did notice that hitting the arrow keys seems to cycle through previous letters and words that I’ve entered into the parser, but does so on this autocomplete bar - not in ScummVM. It seems to be a dictation or autocomplete shortcut bar that is trying to guess words that I am typing. When I do activate it, the bar I was describing pops up, which is neither of the bars you’re describing, but is always present when I am inputting text, as shown in the attachments I’ve added. To answer your initial question, yes I am aware the keyboard does need to be activated. So users might want to see this bar even if they have a physical keyboard (and it also has a key to show the ScummVM menu). My understanding is that iPad keyboard does not have function and escape key. If this is the bar you see, maybe this guesswork does not work on iOS 15.īut I am actually wondering if it might not be better to have a user option to show or not the input accessory bar instead of some guesswork to show it when there is no physical keyboard and hide it when there is one. So we assume that if this is less than 140 point we can hide the bar. Because when a physical keyboard is connected only the bars are visible, the height of the frame is a lot smaller. Basically it looks at the height of the keyboard frame.
#Scummvm ios code#
The code that matters is at the bottom in prepareKeyboard. They is no API to know if a physical keyboard is connected so, so we have to use some guesswork. We also try to hide the input accessory bar if a physical keyboard is connected. But not having such a device this is not something I can experiment with myself. Or maybe there is something more that needs to be done. That works on iOS 12 at least, but maybe that matters for iOS 15. And I just noticed that while we do the later, we set leadingBarButtonGroups and trailingBarButtonGroups to an empty array and not to nil. The UITextInputAssistantItem documentation suggests that setting the leadingBarButtonGroups and trailingBarButtonGroups to nil as well as setting the autocorrection type to UITextAutocorrectionTypeNo should hide the bar.
If that is the bar you see, we may have an issue with this code. This only works on iOS 9 or above (which is your case) when compiled with the iOS 9.0 or above SDK. In ScummVM we try to always hide the input assistant bar. Can you clarify if you mean one of those two or something else? I have attached screenshots for those two. In ScummVM we implemented such a bar to have function keys, arrow keys, escape keys and more. The input accessory bar is a custom bar that applications can implement.The input assistant bar is a standard bar that typically has undo, copy and paste buttons.I have never heard of an accessibility bar, so I don't know if this is something new in recent iOS versions, or if you mean either the input assistant bar or input accessory bar. Regarding the "accessibility bar", I cannot reproduce either, but then I am not sure what you really mean. I am not sure if there is a way with the iOS API to handle generic key press with modifier. Implementing that one a case by case basis would be possible, although not trivial, but we cannot do it for every possible keyboard shortcuts. Shortcut with modifiers was never implemented, so it is expected that they do not work. But now if there is an Escape key it also works properly. And it was indeed never implemented we only add support for using the ` key as escape (which is useful for keyboards that do not have an Escape key). While testing the arrow keys I noticed that the escape key from the keyboard was not working. But since you mention issues with the accessibility bar at the bottom of the screen, I assume you knew that already. One thing to keep in mind is that the keyboard needs to be enabled in ScummVM (for example with a pinch in gesture) before it can be used. And I have no idea why this would not work on iOS 15 or with other keyboards.
#Scummvm ios Bluetooth#
I only have a quite old iPad that is stuck to iOS 12, but with that one I checked that the arrow key from an Apple bluetooth keyboard work as expected in King's Quest II.
0 kommentar(er)
