We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

Philipp, what do you think of using the first solution here: http://stackoverflow.com/questions/7634346/keyboard-hide-event ?

(In reply to comment #2)
> Philipp, what do you think of using the first solution here:
> http://stackoverflow.com/questions/7634346/keyboard-hide-event ?

(I assume your idea is to message SDL if onKeyPreIme() is called with BACK but still let the key close the screen keyboard.)

I have not tested this but it could be a solution for the case where a single BACK would close the screen keyboard. IMO is is no nice solution but better than no solution at all.

If an IME would exist which needs multiple BACK to close and all go through onKeyPreIme() the solution would not work there.

Additional info: For me the screen keyboard also closes if I press HOME and then return (but not if just switching using the recent applications menu). This is another case which may need to be handled later (like all the cases we do not know yet :).

It seems the issue at hand may be harder to solve than previously anticipated. The reason behind this is that, by design, it's not possible to tell if the soft keyboard is up.

Dianne Hackborn from Android states it here: https://groups.google.com/forum/#!topic/android-platform/FyjybyM0wGA

It's hard to believe, but devs have been resorting to a layout change event trick to determine if the keyboard is up, which we can't currently take advantage of (I tried, but we use the AbsoluteLayout, probably because we don't want our OpenGL based view moving or changing sizes...I think, and this means that our view isn't measurably affected by the keyboard coming up). Monitoring via onKeyPreIme (such as when pressing the back button) may work, but as you said there's a ton of combinations to consider, as we would be doing what is essentially a OS task.

I also tried monitoring the focus change events on the DummyEdit widget, this doesn't seem to work either.

Anyway, suggestions welcome.

Just to document my descent into madness...

If we show the keyboard with:

imm.showSoftInput(mTextEdit, InputMethodManager.SHOW_FORCED);

and add a: 

mSurface.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
            @Override
            public void onGlobalLayout() {


You get that event every time the keyboard pop up and down (and then some). If in that function you do:

imm.hideSoftInputFromWindow(mTextEdit.getWindowToken(), InputMethodManager.HIDE_NOT_ALWAYS, result)

That returns true or false, what those values mean is anyones guess (it's not documented). I was thinking that if the keyboard was showing, result will be called with RESULT_UNCHANGED_HIDDEN, and if it's shown it would be RESULT_UNCHANGED_SHOWN or something else, but this isn't the case either. Incredibly, if you try to do a "test hiding" (sort of a quantum experiment where a measurement disturbs the experiment itself), the confirmation that the keyboard is still shown is that...*nothing happens*

Anyway, I think giving LinearLayout or RelativeLayout (instead of AbsoluteLayout) a go and doing like everybody else does it may be the only way to solve this (silly as it may seem!).

(In reply to comment #5)
> Anyway, I think giving LinearLayout or RelativeLayout (instead of
> AbsoluteLayout) a go and doing like everybody else does it may be the only
> way to solve this (silly as it may seem!).

If we go this way, we should pull the target-2.0.0 tag and do this for 2.1...sounds like a risky change at this point.

How hard would wiring up the onKeyPreIme() check be? If it covers most of the use-cases, but will definitely fail in more complicated cases, it's still better than where we are now.

--ryan.

A temporary fix based on the back key detection is here: http://hg.libsdl.org/SDL/rev/d2bc997ef5d6

It seems to work on my Nexus 4, when I press HOME or use the task switch button the keyboards goes away, but it comes back when i return to my app. I'm removing the target-2.0.0 keyword but I'll keep this open so we can solve it properly (or as good as Android lets us).

Filed the enhancement under #2211.