I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard() and
SDL_HideScreenKeyboard() with SDL_StartTextInput() and SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen keyboard
if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen keyboard
if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput() when
you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Also, I noticed that currently the SDL iOS keyboard will hide itself when
you press return. It seems like this makes it worthless for multi-line
text fields.
How do people feel about changing it so it always stays up until you call
SDL_StopTextInput(), which you should do in response to a return key event?
FWIW, thatâs the way the Android implementation works right now.On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga <@slouken> wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen keyboard
if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput() when
you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Does the keyboard hide on its own because of iOS or because SDL is
programmed to do that?
2012/11/5 Sam Lantinga :> Also, I noticed that currently the SDL iOS keyboard will hide itself when
you press return. It seems like this makes it worthless for multi-line text
fields.
How do people feel about changing it so it always stays up until you call
SDL_StopTextInput(), which you should do in response to a return key event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen keyboard
if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput() when
you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
SDL is programmed to do that.On Sun, Nov 4, 2012 at 11:01 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
Does the keyboard hide on its own because of iOS or because SDL is
programmed to do that?
2012/11/5 Sam Lantinga <@slouken>:
Also, I noticed that currently the SDL iOS keyboard will hide itself when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga <@slouken> wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard
if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when
you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Oh well, then yeah, I think it should hide only when SDL_StopTextInput
is called. The more consistent, the better. (note: never programmed
for phones, just suggesting based on those comments)
2012/11/5 Sam Lantinga :> SDL is programmed to do that.
On Sun, Nov 4, 2012 at 11:01 PM, Sik the hedgehog <@Sik_the_hedgehog> wrote:
Does the keyboard hide on its own because of iOS or because SDL is
programmed to do that?
2012/11/5 Sam Lantinga :
Also, I noticed that currently the SDL iOS keyboard will hide itself
when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you
call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard
if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when
you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to
the ShowScreenKeyboard
function?
VittorioOn Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself when
you press return. It seems like this makes it worthless for multi-line
text fields.
How do people feel about changing it so it always stays up until you call
SDL_StopTextInput(), which you should do in response to a return key event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Which is useless because the program could just do StopTextInput when
it detects enter if needed (given itâs already handling the GUI after
all). The function was just hardcoded to close for no real reason.
2012/11/5 Vittorio Giovara <vitto.giova at yahoo.it>:> I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to the
ShowScreenKeyboard function?
Vittorio
On Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself when
you press return. It seems like this makes it worthless for multi-line text
fields.
How do people feel about changing it so it always stays up until you call
SDL_StopTextInput(), which you should do in response to a return key event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Well I would never define a usecase âuselessâ, there are applications that
need multiline input and other the donât: in the first case the current
implementation is problematic but for the second one it is perfect.
Plus writing a single line âSDL_setHint(âHideKeyboardOnReturnâ)â is MUCH
easier than to handle the response of a keypress event (and some
applications donât do that altogether):
Anyway, in my opinion any solution is fine as long as itâs consistent and
uniform on iOS/Android.
Bye,
VittorioOn Mon, Nov 5, 2012 at 10:12 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
Which is useless because the program could just do StopTextInput when
it detects enter if needed (given itâs already handling the GUI after
all). The function was just hardcoded to close for no real reason.
2012/11/5 Vittorio Giovara <vitto.giova at yahoo.it>:
I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to the
ShowScreenKeyboard function?
Vittorio
On Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself
when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you
call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
As far as I know you are given every character in its own event
anyway, and handling the enter key would just be part of that.
Which brings me to another point, the text input events have nearly
non-existent documentation other than the functions and structs exist,
itâs impossible to tell how they work until you actually use them -
and even then youâre bound to get it wrong (especially with
SDL_SetTextInputRect, what is it meant to set exactly? trial and error
wonât work because I could end up hitting some undefined behavior by
accident and it break later on other platforms or later SDL versions)
Also Iâd rather pass it as a parameter if implemented, since hints are
for things that stay the same across the execution (and them changing
in the middle is an exception to the rule), as well as being able to
be set by environment variables (so you should avoid messing with them
unless strictly required), while single and multiline edits are both
pretty common - you may even need both at the same time (e.g. a form
with multiple fields, some single line and some multiline).
2012/11/6 Vittorio Giovara <vitto.giova at yahoo.it>:> Well I would never define a usecase âuselessâ, there are applications that
need multiline input and other the donât: in the first case the current
implementation is problematic but for the second one it is perfect.
Plus writing a single line âSDL_setHint(âHideKeyboardOnReturnâ)â is MUCH
easier than to handle the response of a keypress event (and some
applications donât do that altogether):
Anyway, in my opinion any solution is fine as long as itâs consistent and
uniform on iOS/Android.
Bye,
Vittorio
On Mon, Nov 5, 2012 at 10:12 AM, Sik the hedgehog <@Sik_the_hedgehog> wrote:
Which is useless because the program could just do StopTextInput when
it detects enter if needed (given itâs already handling the GUI after
all). The function was just hardcoded to close for no real reason.
2012/11/5 Vittorio Giovara <vitto.giova at yahoo.it>:
I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to
the
ShowScreenKeyboard function?
Vittorio
On Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself
when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you
call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced
SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are
accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
â drawocOn Tue, Nov 6, 2012 at 5:26 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
As far as I know you are given every character in its own event
anyway, and handling the enter key would just be part of that.
Which brings me to another point, the text input events have nearly
non-existent documentation other than the functions and structs exist,
itâs impossible to tell how they work until you actually use them -
and even then youâre bound to get it wrong (especially with
SDL_SetTextInputRect, what is it meant to set exactly? trial and error
wonât work because I could end up hitting some undefined behavior by
accident and it break later on other platforms or later SDL versions)
Also Iâd rather pass it as a parameter if implemented, since hints are
for things that stay the same across the execution (and them changing
in the middle is an exception to the rule), as well as being able to
be set by environment variables (so you should avoid messing with them
unless strictly required), while single and multiline edits are both
pretty common - you may even need both at the same time (e.g. a form
with multiple fields, some single line and some multiline).
2012/11/6 Vittorio Giovara <vitto.giova at yahoo.it>:
Well I would never define a usecase âuselessâ, there are applications that
need multiline input and other the donât: in the first case the current
implementation is problematic but for the second one it is perfect.
Plus writing a single line âSDL_setHint(âHideKeyboardOnReturnâ)â is MUCH
easier than to handle the response of a keypress event (and some
applications donât do that altogether):
Anyway, in my opinion any solution is fine as long as itâs consistent and
uniform on iOS/Android.
Bye,
Vittorio
On Mon, Nov 5, 2012 at 10:12 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
Which is useless because the program could just do StopTextInput when
it detects enter if needed (given itâs already handling the GUI after
all). The function was just hardcoded to close for no real reason.
2012/11/5 Vittorio Giovara <vitto.giova at yahoo.it>:
I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to
the
ShowScreenKeyboard function?
Vittorio
On Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself
when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you
call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced
SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are
accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
It still isnât very clear: Iâm still clueless as to what
SDL_SetTextInputRect should specify exactly (in fact the tutorial and
the reference for said function even seem to contradict each other).
Also back on-topic, I was wondering: if the keyboard closes on its
own, how does the program know it happened? Since text input should
stop there after all.
2012/11/6 drawoc :> There are some docs on the wiki:
On Tue, Nov 6, 2012 at 5:26 AM, Sik the hedgehog <@Sik_the_hedgehog> wrote:
As far as I know you are given every character in its own event
anyway, and handling the enter key would just be part of that.
Which brings me to another point, the text input events have nearly
non-existent documentation other than the functions and structs exist,
itâs impossible to tell how they work until you actually use them -
and even then youâre bound to get it wrong (especially with
SDL_SetTextInputRect, what is it meant to set exactly? trial and error
wonât work because I could end up hitting some undefined behavior by
accident and it break later on other platforms or later SDL versions)
Also Iâd rather pass it as a parameter if implemented, since hints are
for things that stay the same across the execution (and them changing
in the middle is an exception to the rule), as well as being able to
be set by environment variables (so you should avoid messing with them
unless strictly required), while single and multiline edits are both
pretty common - you may even need both at the same time (e.g. a form
with multiple fields, some single line and some multiline).
2012/11/6 Vittorio Giovara <vitto.giova at yahoo.it>:
Well I would never define a usecase âuselessâ, there are applications that
need multiline input and other the donât: in the first case the current
implementation is problematic but for the second one it is perfect.
Plus writing a single line âSDL_setHint(âHideKeyboardOnReturnâ)â is MUCH
easier than to handle the response of a keypress event (and some
applications donât do that altogether):
Anyway, in my opinion any solution is fine as long as itâs consistent and
uniform on iOS/Android.
Bye,
Vittorio
On Mon, Nov 5, 2012 at 10:12 AM, Sik the hedgehog <@Sik_the_hedgehog> wrote:
Which is useless because the program could just do StopTextInput when
it detects enter if needed (given itâs already handling the GUI after
all). The function was just hardcoded to close for no real reason.
2012/11/5 Vittorio Giovara <vitto.giova at yahoo.it>:
I welcome the API change, Sam!
For the multiline problem, how about a SDL_Hint, or passing a bool to
the
ShowScreenKeyboard function?
Vittorio
On Mon, Nov 5, 2012 at 7:54 AM, Sam Lantinga wrote:
Also, I noticed that currently the SDL iOS keyboard will hide itself
when
you press return. It seems like this makes it worthless for multi-line
text
fields.
How do people feel about changing it so it always stays up until you
call
SDL_StopTextInput(), which you should do in response to a return key
event?
FWIW, thatâs the way the Android implementation works right now.
On Sun, Nov 4, 2012 at 10:52 PM, Sam Lantinga wrote:
I just checked in a pretty big change to the on-screen keyboard API.
The quick and dirty version is that I replaced
SDL_ShowScreenKeyboard()
and SDL_HideScreenKeyboard() with SDL_StartTextInput() and
SDL_StopTextInput().
Here are the full notes:
Synchronized the on-screen keyboard state with whether we are
accepting
text input.
The functions to show/hide/toggle the on-screen keyboard have been
folded
into the text input state.
Calling SDL_StartTextInput() will automatically show the on-screen
keyboard if itâs available.
Calling SDL_StopTextInput() will automatically hide the on-screen
keyboard if itâs available.
There is a new API function SDL_IsTextInputActive() which will return
whether text input is currently active.
Text input is disabled by default, you must call SDL_StartTextInput()
when you are ready to accept text input.
SDL_HasScreenKeyboardSupport() no longer needs to be passed a window.
The iPhone-specific on-screen keyboard functions have been removed.
Hi Sam, I have just downloaded this update. (8 - Nov update)
The update has fixed some file issues that I was having. But now the keyboard is showing up when my application starts; I have commented out my code that calls the keyboard and that hasnât fixed the problem.
Can you think of what might be the problem?
Also is there a way that I can get the size of the soft keyboard, as I would like to adjust my screen when the keyboard is visible.
There currently isnât any API to get the size of the on-screen keyboard,
though I agree that would be useful. Patches welcome! :)On Mon, Nov 12, 2012 at 7:31 PM, BJ wrote:
**
Hi Sam, I have just downloaded this update. (8 - Nov update)
The update has fixed some file issues that I was having. But now the
keyboard is showing up when my application starts; I have commented out my
code that calls the keyboard and that hasnât fixed the problem.
Can you think of what might be the problem?
Also is there a way that I can get the size of the soft keyboard, as I
would like to adjust my screen when the keyboard is visible.
Ok, the good news is that the keyboard no longer shows on start up.
Some suggestions, currently when the back button is pressed the engine has no record of this press if the keyboard is visible. The button event is received if the keyboard is hidden.
The other one is to get the height of the keyboard when visible.
I need both of these so that I can adjust the screen when the keyboard is visible and return it to normal when it isnât.
I am very new to android coding, so I am not much help here. I have been trying to figure out how to do these, with out success.
Itâs been a while but Iâve encountered the multi-line input problem. For now I have had to hardcode the case of the return key to just call SDL_StartTextInput(); again. So the on screen keyboard is making little jumps when I press return but this seems to be the only good way to do it.
Iâd very much prefer it for the keyboard to stay up until I tell it to stop.
Iâve added a bugreport + patch at https://bugzilla.libsdl.org/show_bug.cgi?id=4004
BUT it would probably make sense to merge the iOS hint in my patch with the Android IME hint. But the defaults are different.
