Adding SDL_HINT_IME_PAN_PADDING "SDL_IME_PAN_PADDING".#15048
Adding SDL_HINT_IME_PAN_PADDING "SDL_IME_PAN_PADDING".#15048DominusExult wants to merge 3 commits intolibsdl-org:mainfrom
Conversation
Controls the padding between TextInputArea and IME and defaults to 0.
|
Actually, I didn't realize that we already applied a 15 pixel padding. The default should be unchanged behavior, so I guess 15. |
…t with previous look. Also seems that I was mistaken about the padding automatically applied by iOS.
|
Right, so now 15 is the default, meaning that TestIME doesn't need the hint (even though adding a hint set to 20 wouldn't be too bad and tests/shows the hint as well, which might be a good place for it). |
include/SDL3/SDL_hints.h
Outdated
| * to ensure there is extra breathing room between the text input area and | ||
| * the top of the keyboard when panning the view. | ||
| * | ||
| * The variable can be set to a number representing the padding in pixels. |
There was a problem hiding this comment.
| * The variable can be set to a number representing the padding in pixels. | |
| * The variable can be set to a number representing the padding in window coordinates. |
I used the word pixels, but technically this is window coordinates, right?
There was a problem hiding this comment.
I‘m not really sure what unit is actually used, just that you used 15 of it on Android and it‘s only the same for iOS when you divide by the scale factor to get points. So pixel is right I think. But I‘m getting confused.
There was a problem hiding this comment.
Android uses pixels and iOS uses points. The conversion you're doing in testime is what you'd do for this value too.
| int rectbottom = (int)(self.textInputRect.y + self.textInputRect.h); | ||
| /* Get the pan padding from the hint (in pixels). The text input rect | ||
| * and view bounds are in UIKit points, so divide by the scale factor | ||
| * to keep the visual gap consistent across platforms.*/ |
There was a problem hiding this comment.
This should use the same units as the text input rect and view bounds.
| const char *hint = SDL_GetHint(SDL_HINT_IME_PAN_PADDING); | ||
| int panPadding = (hint && *hint) ? SDL_atoi(hint) : 15; | ||
| int padding = (int)(panPadding / self.view.contentScaleFactor); | ||
| int rectbottom = (int)(self.textInputRect.y + self.textInputRect.h + padding); |
There was a problem hiding this comment.
The previous padding value was 0, so we need to subtract 15, right?
There was a problem hiding this comment.
I was wrong about the automatic padding on iOS, so 0 in int panPadding = (hint && *hint) ? SDL_atoi(hint) : 0; was actually setting it to no padding by default and now 15 is adding the new default.
I have no idea why I saw a padding and now don't see it with padding set to 0. Probably too many windows open with too many branches.
There was a problem hiding this comment.
Does it look consistent with the Android version with 15 points of padding?
There was a problem hiding this comment.
With the division it looks consistent.
There was a problem hiding this comment.
Okay, so what you want to do is set the hint in testime, and use the same conversion to window coordinates calculation on the hint value.
There was a problem hiding this comment.
@slouken is this correct now? I'm really struggling with window coordinates, points and pixels, but window coordinates equals points, so no conversion for iOS. And is the conversion to pixels correct (window coordinates * density)?
It looks almost equal with different paddings while on Android the padding looks just a tiny bit more. Probably would need visual help in TestIME to really tell :)
There was a problem hiding this comment.
Points == pixels on Android, so no conversion is needed there either. Basically, no conversion is necessary in SDL code for either platform. You're so close! :)
There was a problem hiding this comment.
But... I don't understand this then.
If I don't apply any conversion, the padding on either platform is visibly far from the same.
Applying the Android conversion makes it close but not quite the same (the higher the padding the more it drifts apart). I'm really at a loss at how to do this properly.
TestIME padding of 50, and as a visual guide I've added the setting_icon a couple of times (input at 250.0f, both show 5 + something setting icons underneath without the IME).
No conversion iOS (and incidentally my conversion attempt shows the same):
No conversion Android: Conversion Android:
There was a problem hiding this comment.
Okay, I'll go ahead and merge this and clean it up afterwards.
There was a problem hiding this comment.
Thank you, looking forward to see/learn what is the right way.
…ert for Android. Default is now 10 window coordinates (slightly more than 15 pixels).
2 participants
Controls the padding between TextInputArea and the on screen keyboard on iOS and Android (and defaults to 0).
Description
When the SDL_SetTextInputArea is obscured by the on screen keyboard on Android and iOS, the screen pans upward to have a clear view of the input area.
Previously a padding of 15 pixels between IME and input area was hardcoded on Android and it seems to me as if the iOS on screen keyboard applies a 15 pixels padding (or reports the keyboard to be 15 pixels taller than it really is).
In the Android code the default padding is set to 0 and on iOS the 15 pixels get subtracted to have a default 0 pixel padding.
When PR #15046 is applied, testime.c could need an
SDL_SetHint(SDL_HINT_IME_PAN_PADDING, "15");around line 662.Let me know if you want the hint to have another name.
Existing Issue(s)