Opened 8 years ago

Last modified 2 years ago

#712 reopened enhancement/feature request

Enable use of smartphone's own 'software' keyboard

Reported by: dirk205 Owned by:
Priority: minor Milestone: version 0.5.1
Component: core Version: git master
Severity: normal Keywords: keyboard wince android i18n
Cc: https://wiki.navit-project.org/index.php/user:tryagain, http://wiki.navit-project.org/index.php/user:mvglasow, (2)

Description

Please consider using the build-in keyboard.

Attachments (1)

HTC Tastatur.png (95.8 KB) - added by dirk205 8 years ago.
HTC HD2

Download all attachments as: .zip

Change History (32)

Changed 8 years ago by dirk205

HTC HD2

comment:1 Changed 8 years ago by mineque

  • Resolution set to fixed
  • Status changed from new to closed

Please check wiki, there is many usefull information ;)

http://wiki.navit-project.org/index.php/Gui_internal#Configuration

If your OS provides you with a keyboard that you prefer to the one navit gives you, you should try setting

 keyboard="false"

inside the <gui .../> tag.

comment:2 Changed 8 years ago by dirk205

  • Resolution fixed deleted
  • Status changed from closed to reopened

Thanks for the hint, I tried with keyboard="false" flag. Unfortunately my keyboard does not show up by itself, presumably the OS is not aware that an input can be made. I can only get the keyboard by using the bug mentioned in ticket #713, then it works.

comment:3 Changed 8 years ago by mineque

so button can be displayed all the time or OS have to know you want to write sth (input field present)?

comment:4 Changed 8 years ago by dirk205

OS have to know you want to write sth (input field present)

This is correct. It is not visible all the time. BTW, I use fullscreen mode always.

comment:5 Changed 8 years ago by mineque

on other ticket you say it is visible on the map where arent any input fields present?

comment:6 Changed 8 years ago by dirk205

Yes, when I change to another app on the device (i.e. to make a screen shot) and go back the icon pops up and does not vanish... Maybe an error in Win Mobile but perhaps you can issue a command to steer its presence?

comment:7 Changed 8 years ago by korrosa

  • Summary changed from some smartphones have an own keyboard to Enable use of smartphone's own 'software' keyboard

comment:8 Changed 7 years ago by aaaapublic

Is there anything being done on this ? I think this is getting progressively more important as more people use Navit and need non-English/Latin?.

I think it is not productive for the Navit team to provide keyboards for every possible language, when perfectly good ones already exist in the mobile device. Eg, I use Asian maps and I need to input text in Chinese. I cannot do this with Navit's keyboard, but my Android phone has perfectly good keyboard support for this language.

I have tried the keboard="false" option, but then the builtin keyboard does not appear when I select a input text field. I have to hold down the menu button to force it to appear. But in landscape mode, even this does not work, and the builtin Android keyboard will not appear at all. Please look into it. Thanks.

comment:9 Changed 7 years ago by korrosa

Press-and-hold of the Menu button to make the Android keyboard show on an Android device works fine for me in both portrait and landscape modes. Can anyone else confirm the no-show in landscape mode, and what devices you're using?

comment:10 Changed 7 years ago by aaaapublic

I originally reported this on my Galaxy S (with DarkyROM ) which I no longer have. Now I just tested it on my Galaxy Note (Stock ROM 2.3.5) with GO Keyboard, and the behavior is the same : the keyboard shows up in Portrait mode when I hold down the menu button, but not in Landscape mode.

And here's the interesting part : I switched to the stock Samsung keyboard, restarted Navit and the keyboard poped up once in the portrait mode. But subsequently it will NOT show up in both portrait and landscape mode !

The version of Navit I have is from one of the SVN builds - version 0.5.0.4944

comment:11 Changed 7 years ago by korrosa

OK, I've done some further testing.

Device
Samsung Galaxy SII (GT-I9100)
Android 2.3.4 (stock TouchWiz?, not rooted)

Scenario 1

  • Keyboard: Samsung default
  • Navit: r4952
  • Hold Menu key: keyboard does NOT show in landscape mode
  • Hold Menu key: keyboard DOES show in portrait mode
  • Subsequent attempts of holding Menu: keyboard shows FINE in portrait, NEVER shows in landscape

Scenario 2

  • Keyboard: Swype
  • Navit: r4952
  • Hold Menu key: keyboard DOES show in landscape mode
  • Hold Menu key: keyboard DOES show in portrait mode
  • Subsequent attempts of holding Menu: keyboard shows FINE in portrait, and FINE in landscape

Hope that helps!

comment:12 Changed 7 years ago by korrosa

  • Component changed from port/wince to core
  • Keywords wince android added

comment:13 Changed 7 years ago by aaaapublic

I've retested it with the Swype keyboard on my Galaxy Note(2.3.5, stock, no root), to see if I can reproduce korrosa's Scenario 2.

The behavior is the same as in my previous post. The Swype keyboard shows up in portrait mode, but does NOT show up in landscape mode, which is different from korrosa's test.

Seems like the behavior depends on the combo of device, Android version, and keyboard type.

comment:14 Changed 7 years ago by tryagain

HTC Wildfire S (no root) shows keyboard, but this behavior seems to depend of what application is running on the background.

If there's a telephone application, I'm able to call only some system default keyboard which I never seen before, it allows only digits, #,$, P and W symbols to be entered.

If I switch to an already running Navit application from editing a Contact, I'm able to call the usual keyboard which can change modes alpha/numeric and languages.

But I'm unable to enter Cyrillic chars, most probably that is because Android uses its own Unicode representation.

comment:15 Changed 6 years ago by fred jelk

In the wiki-page http://wiki.navit-project.org/index.php/Navit_on_Android#Keyboard , its noted "To use your default Android keyboard instead, just press and hold your device's Menu button until the keyboard pops up". But, which Menu button? On my devices (Galaxy Nexus and Nexus 4) there is no Hardware-Menu Button. So, how can I use the default Android Keyboard on these devices? Its really not pleasant to use the Navit-own-keyboard - a qwerty/qwertz-software-keyboard will be much better. It should be possible, to enable the android-software-keyboard as default.

Last edited 6 years ago by fred jelk (previous) (diff)

comment:16 Changed 5 years ago by usul

  • Milestone set to version 0.5.1

There is also a post on the forum fokussing this issue: https://forum.navit-project.org/viewtopic.php?f=19&t=419
As this seems to be a big problem which results in a major problem to use Navit on Android, I suggest to fix it within the next hotfix release.

comment:17 Changed 5 years ago by usul

  • Keywords i18n added

comment:18 Changed 5 years ago by dart

Confirm issue reported by tryagain - can't enter Cyrillic with Android keyboard. Samsung i9000, CyanogenMod? 10.1.2

comment:19 Changed 5 years ago by tryagain

  • Cc https://wiki.navit-project.org/index.php/user:tryagain added

After os upgrade on my wildfire s, it seems to be much easier to get keyboard. And it's always good one, allowing to switch input languages and so on. Cyrillic (altogether with accented latin) input is not working, but i expect it to be two-liner patch to fix it.

Showing system kbd i expect to be only a bit harder. We should take care to not pollute internal gui code with android specifics. Probably this best could be done by setting new graphics atribute vkbd_mode. Values of it would correspond to current internal keyboard modes. In that patch, we should define constants in graphics.h for posible vkbd_mode values.

comment:20 Changed 3 years ago by mvglasow (2)

  • Severity set to normal

Just tried <gui ... keyboard="false"> on Android. The internal keyboard does not show, but the Android keyboard does not show either, and I am not I aware of any way to show the keyboard manually.

Not polluting the GUI code with platform-specific stuff is a valid point.

As the keyboard is managed by the graphics driver (which is platform-specific), we could simply provide some hook (an extra callback or the like) through which the GUI tells the graphics driver that a keyboard is needed. That would be the case e.g. when text input is expected and the internal GUI keyboard is disabled.

The graphics driver can then implement any additional logic to launch a keyboard or other input method. For instance, the graphics driver might not launch the on-screen keyboard if a hardware keyboard is present (though this behavior could be configurable).

About vkbd_mode, keyboards on the different system platforms might work quite differently from the Navit one. For example, in Android the user can select a bunch of layouts and switch between them, but it would probably be hard to do things such as switching between Latin and Cyrillic. Suppose the user has two different Latin layouts installed but no Cyrillic one. When vkbd_mode=vkbd_latin_lowercase, which of the two layouts should be selected? And what if vkbd_mode=vkbd_cyrillic_lowercase? Admittedly, I need to dig a bit deeper into internal keyboard modes, as well as interfacing with the Android keyboard.

comment:21 follow-up: Changed 3 years ago by mvglasow (2)

Actually we can do a somewhat rough translation of the keyboard mode. Details will depend on the platform implementation and will likely differ between platforms.

Latin, Cyrillic and Umlaut modes will select the platform's default alphanumeric layout. The respective uppercase modes will switch the platform keyboard to uppercase. For special characters and non-Latin alphabets we will need to rely on the user having the appropriate layout installed and switching as needed. It probably makes sense to pass the country code along with the mode. That allows the platform implementation to make a more precise guess on the keyboard layout that is needed (and support alphabets/characters that are not currently covered by the internal keyboard).

Numeric mode will select a numeric keyboard (if available on the platform). Degree mode might also select a numeric keyboard with some extra characters – again subject to availability on the platform.

comment:22 in reply to: ↑ 21 Changed 3 years ago by tryagain

Replying to http://wiki.navit-project.org/index.php/user:mvglasow (2):

Actually we can do a somewhat rough translation of the keyboard mode. Details will depend on the platform implementation and will likely differ between platforms.

Exactly!

comment:23 Changed 3 years ago by mvglasow (2)

I tried a few things over the past few days. As far as the internal GUI is concerned, providing the hooks for a native virtual keyboard isn't that hard.

The tricky part is the platform itself. Android isn't particularly supportive about apps showing and hiding the keyboard at will, thus a lot of hackery is required to get around the limitations of the API. There is a call to show and to hide the keyboard (along with a flag essentially specifying how badly you want that to happen) but no reliable way to determine if the keyboard is actually showing or how much space it occupies.

And we're not even talking about layouts here – there is no direct way to request any layout when opening the keyboard. The only way to do that is by setting certain parameters on the associated View. However, they are merely hints which the input method is free to consider or ignore, and are only available with TextViews?. We might try by having NavitGraphics extend TextView rather than View, hoping that this won't have any other undesired side effects. Maybe I can find out something from the Android source code.

Let's hope other platforms are more supportive about showing an internal keyboard.

comment:24 Changed 3 years ago by mvglasow (2)

About layouts, it turns out there may be a way to do that with Views other than TextView: The View class has a member function, onCreateInputConnection(), which the TextView class uses to supply all information relevant for layout selection to the input method. The default implementation in View returns null, but subclasses can override it in a similar manner TextView does.

Documentation at: http://developer.android.com/reference/android/view/View.html#onCreateInputConnection%28android.view.inputmethod.EditorInfo%29

TextView implementation: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/widget/TextView.java#TextView.onCreateInputConnection%28android.view.inputmethod.EditorInfo%29

Still the information supplied here is just a hint and it's up to the input method to decide how (or if at all) to deal with it. That is mostly due to the fact that input method implementations can vary considerably, including not only on-screen keyboards but also things such as stroke recognition (remember Palm's Graffiti or Pocket Windows' Scribble?), possibly even handwriting recognition or some more exotic ones. For instance, jog-dial controls, commonly found in car navigation systems (turn a knob to cycle through characters, press to add a character), could also be implemented as input methods.

The good news is that, since this is the same mechanism employed by TextView, the keyboard should behave the same as it does in pure Android apps.

Last edited 3 years ago by mvglasow (2) (previous) (diff)

comment:25 Changed 3 years ago by mvglasow (2)

There are a few difficulties with translating Navit's keyboard modes to Android:

Navit has modes for Latin and Cyrillic scripts, as well as another one for umlauts, both in upper and lower case. Additionally there is a numeric mode and a "degree mode", which is essentially numeric mode with a few extra keys (degrees, minutes and N/E/S/W). With the exception of degree mode, each mode allows switching to other modes.

Android does not support selection of scripts or local layouts via the API – the user needs do have the respective local layout installed and switch manually. At the most we can switch between upper and lower case. The default AOSP keyboard has a numeric mode, but the user cannot switch from numeric mode to any other mode. On the other hand, numbers and special characters are also available as a third layer from text mode. Umlauts and other diacritics (accents etc.) are also available. This depends on the layout, but most AOSP layouts have these characters for multiple languages – and Navit is smart enough to map s to š and similar.

Navit starts the internal keyboard in either Latin or Cyrillic mode in most cases. The only exceptions are house numbers (numeric mode) and coordinates (degree mode).

On Android that would mean using text mode wherever Navit uses Latin or Cyrillic. House numbers may also contain letters, preventing us from using the numeric keyboard as the user has no way to enter letters in that mode. Coordinate entry also requires characters not available in numeric mode.

Bottom line: on Android we need text mode for all entries Navit currently supports. The only useful thing we can do in onCreateInputConnection() is to switch the keyboard to caps mode – either on the first character, or on the first character of each word (i.e. after every space), or permanently.

I conducted a few tests with onCreateInputConnection(). The method is supplied an EditorInfo attribute in which one can, in theory, set parameters that affect the keyboard layout.

The inputType field can be set to TYPE_CLASS_TEXT (for text input), TYPE_CLASS_NUMBER (for number input) or TYPE_NULL. The latter is described in the documentation as follows:

This should be interpreted to mean that the target input connection is not rich, it can not process and show things like candidate text nor retrieve the current text, so the input method will need to run in a limited "generate key events" mode, if it supports it. Note that some input methods may not support it, for example a voice-based input method will likely not be able to generate key events even if this flag is set.

Flags for caps mode can also be set in inputType. There is also a field initialCapsMode.

A limitation is that onCreateInputConnection() is called only once when the view is created – for Navit that means once during the entire lifecycle of the app. Thus switching parameters becomes an issue.

In my tests initialCapsMode never took effect. The only way to change caps mode was through inputType flags, such as TYPE_CLASS_TEXT | TYPE_TEXT_FLAG_CAP_WORDS.

However, the backspace key will not work unless inputType is TYPE_NULL. Even combinations such as TYPE_NULL | TYPE_TEXT_FLAG_CAP_WORDS will break it.

Bottom line: any way of switching to caps automatically will break the Backspace key – unless we provide for a lot more interaction between the Navit UI and the input method, which may get complex.

For now I guess I'll stick with the basic keyboard support – it may have some minor limitation but works in general. That code needs some cleanup and will then be ready for a merge. All it takes is a keyboard=false attribute in the gui section, which causes Navit to suppress its own keyboard and use the native one if available.

Anyone who'd like to use soft input on a platform other than Android can then build upon that and implement the specific part for their platform.

comment:26 Changed 3 years ago by mvglasow (2)

Cleaned up the code, here's the pull request: https://github.com/navit-gps/navit/pull/46 https://github.com/navit-gps/navit/pull/47 (original request revoked due to CI issue) https://github.com/navit-gps/navit/pull/50 (rebased commits for a more legible history)

Last edited 3 years ago by mvglasow (2) (previous) (diff)

comment:27 Changed 3 years ago by mvglasow (2)

  • Cc http://wiki.navit-project.org/index.php/user:mvglasow (2) added

comment:28 Changed 2 years ago by mvglasow (2)

The last commit in the pull request had to be reverted, see https://github.com/navit-gps/navit/commit/1e638f6e57a0e0d6d691b08fcd27a6b610a6b362. It apparently introduced a regression with POI search results being empty – strangely enough, only on Linux, not on Android.

It's seven months ago since I committed this piece of code, thus my memory of it isn't all that fresh any more...

IIRC, the issue that https://github.com/navit-gps/navit/commit/53b333a617146bc304063f8ddd0dfe2927bb6064 (my original commit) intended to fix was the following: When using the native keyboard on Android, it would keep popping up on top of the search results. I couldn't quite figure out what was causing the keyboard to reappear, thus the code was mostly a result of poking around until it seemed to work.

Any help from someone with in-depth knowledge of the internal GUI (including the keyboard) would be appreciated.

comment:29 Changed 2 years ago by tryagain

Hi!

I probably was not clear: the problem exists both on linux and Android.

It is related to the way how internal gui menu stacking works. Internal gui holds all parent menus in memory while any child menu is active. When child menu is closed, we have its parent just in the same state as user left it. Also, child menu may access data from the parent menu when it needs it.

So killing parent menu as was done in the reverted commit, makes navit access already freed memory regions. That memory may for a while still contain the needed data, so search in some conditions happens to work. When things go wrong, the needed data is overwritten before it's accessed by the child menu.

Also, with that commit, we completely lost ability to return one step back to refine the query string without entering it anew.

So my idea is to analyze if current focused widget accepts keyboard input, and fire up keyboard if it does. If current focused widget does not accept keyboard input, keyboard should be closed. That analysis probably could be done in widget rendering code.

I think we should not reserve screen space below the system keyboard. When user is finished with entering query string, they can hide keyboard and see results which were obscured.

So we should care not to bring keyboard back once it's closed by direct user action, even if input field is still focused. For example, we can keep the data, which widget activation has fired up the keyboard, and do not bring it back until it lost and regain the focus.

We'll have to provide intuitive way to bring keyboard back after it has gone. That could be done same way as we do it currently with minimized gui internal keyboard: a one line widget with an up arrow. Or, even better, provide "show/hide keyboard" button near each text input widget.

tryagain.

comment:30 Changed 2 years ago by tryagain

My 4.2.2 device seems to be affected by the bug described here: http://stackoverflow.com/questions/18581636/android-cannot-capture-backspace-delete-press-in-soft-keyboard

In short, soft keyboard doesn't feed application with any characters in response to backspace key press, logging messsage "E/LatinIME(10871): Backspace when we don't know the selection position"

I did not test to work it around as described in the post.

Update:

I have posted my vision of this feature to https://github.com/navit-gps/navit/tree/android-software-keyboard.

It's controlled by internal gui "keyborad" value: 0 - no sw keyboard at all, 1 - gui internal kb, 2 - system sw keyboard. These values look more intuitive for me.

Please note, it does not solve the above problem, so it's too early to set keyboard=2 by default.

But I don't think pushing it to trunk would hurt anybody besides those having custom navit.xml on android with keyboard=0 set.

Last edited 2 years ago by tryagain (previous) (diff)

comment:31 Changed 2 years ago by tryagain

I had some spare time and adopted aforementioned solution from stackoverflow.

Now it works fine on my device.

BTW, I have noticed http://wiki.navit-project.org/index.php/Gui_internal#Configuration recommends to use keyboard="false" attribute to gui. It's misleading, keyboard is numeric, not boolean parameter.It treats any non-numeric value string as zero, so keyboard="false" and keyboard="true" are equivalent.

Note: See TracTickets for help on using tickets.