Open torappinfo opened 4 years ago
It works fine for me (and has always worked fine). You need to provide more details.
I use the Norwegian layout in Gboard, which has the non-ascii characters æ, ø and å and they work.
I also have no issues with Gboard. Is it a particular language?
do you have similar issues with any other keyboard?
Any character examples? or screenshots?
At least for me, Termux forces Gboard into QWERTY mode, and won't let you switch to another language.
To input other languages, you need to use Termux's "text input view" (swipe left on the function key bar); in that mode, all Gboard languages work.
This really isn't very difficult, but maybe it's not so obvious to new users...
I can switch to other languages/layouts by long pressing the space bar, no matter if the text input view is active or not. It's not forced to qwerty either.
only ascii keyboard can be used
There is a keyboard that builds in Termux on device. It's called simple-keyboard and can be easily built in Termux with buildAPKs.developers.tools. All the languages in the system are available through settings.
I can switch to other languages/layouts by long pressing the space bar, no matter if the text input view is active or not. It's not forced to qwerty either.
I wonder if this is Android-version specific.... I'm on Android 7.0.
Could be. I'm on Android 10 on a Pixel 3.
My problem solved when I switched to different keyboard which doesn't have features like autocorrect, autocomplete or predictive text...You can try turning off predictive text
Simply turn off automatic remediation and autocomplete, or use another keyboard as keyboard hackers
My experience is the same, and turning off spell check and input prediction will not help.
Changing the input method can certainly work, but the premise is that the design of the input method itself does not meet the specifications.
Termux's code is programmed to use a char-based keyboard for regular input, to ensure this, termux added an property in its configuration file(~/.termux/termux.properties), namely enforce-char-based-input.
This property is not true by default, because termux believes that the correctly implemented input method has same effects when using input.TYPE_NUL, just like gboard. Only when necessary, set its value to true, those other input methods with different behaviors of input.TYPE_NUL will become like gboard and only display the visible password keyboard.
Obviously, the visible password keyboard or none(default) keyboard in gboard both will not display any extra buttons, such as settings, clipboard, character selection, etc. This does bring some inconvenience, at least, for me. Using two-line shortcut keys and pre-input text box to make up for the lack of password keyboard is a solution.
@YanceyChiew When using gboard, the input type set as
outAttrs.inputType = InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS;
may cause keyboard to overlap the extra keys row on some configurations.
Before:
After:
In case of disabled extra keys, it will overlap few lines of command prompt.
may cause keyboard to overlap the extra keys row on some configurations.
Seems like a bug in the rom, android handles pushing up the view itself. It's done by WindowManager.LayoutParams.SOFT_INPUT_ADJUST_RESIZE
flag which is set by Termux. Although, the flag is deprecated in API 30, but it still should work properly, maybe using WindowInset
API fixes the issue. What's the android version? Working fine on my LG G5 Android 7.0
, also language switching works.
What's the android version?
Android 11 from Pixel 5.
Thanks. Will look into in future. Working fine on pixel 3a android 11 avd though.
@agnostic-apollo Do you have the latest gboard installed and clipboard suggestions enabled?
Well, I was on the preinstalled version 9.4.11.312687073-preload-x86
, but I updated to latest version 10.5.03.367007960-release-x86
. I did enable clipboard suggestions but working fine still, but that shouldn't affect hiding of extra keys since suggestions don't show in terminal view, with and without ctrl-space-workaround
enabled. That's only for input text view, in which extra keys don't show anyways. And "few lines of command prompt" are also not overlapped if extra keys are disabled.
I have the same behavior on my Android 9 Gigaset (same Gboard version like @xeffyr but armv7). The one Extra Key line (shot1) contains Ctrl (^
) and KEYBOARD
-toggle. After Copy the selected text is displayed over the Extra Key line (shot2). Toggling is no longer possible only after back key (shot3). However, the line remains after again "On-Toggle".
The CRTL+Space
workaround does not work because ^
is hidden. But there are other workarounds such as Hacker/Gboard toggle. Paste removes the clipboard info but not the line. In the gboard settings I have found no clipboard line=off
or similar. But possibly have you @agnostic-apollo more success (I prefer Clipboard in mind instaed on screen).
With most of your last changes, I am very satisfied, except for a few workarounds that remained ff. In the meantime, the "Discord kids" have also discovered "T: X11" and are increasingly changing from VNC to this Xserver. Therefore again the request about common Extra Keys.
So I did some more testing. On Android 11 avd, the clipboard suggestion bar don't show when text is copied with ctrl-space-workaround=true
and its setting enabled in gboard setttings. It does show on Android 7 LG G5.
This seems like an OS bug to me, android is responsible for pushing up the view depending on keyboard height. In my logcat
, when clipboard suggestions bar is showing or not, for both cases, the following entries exist, when keyboard is opened
I/KeyboardViewUtil: KeyboardViewUtil.getKeyboardHeightRatio():166 systemKeyboardHeightRatio:1.000000; userKeyboardHeightRatio:1.000000.
I/KeyboardViewUtil: KeyboardViewUtil.calculateMaxKeyboardBodyHeight():62 leave 500 height for app when screen height:2392, header height:176 and isFullscreenMode:false, so the max keyboard body height is:1716
I/KeyboardViewUtil: KeyboardViewUtil.calculateMaxKeyboardBodyHeight():62 leave 500 height for app when screen height:2392, header height:176 and isFullscreenMode:false, so the max keyboard body height is:1716
I/NormalModeController: NormalModeController.getKeyboardBodyViewHolderPaddingBottom():114 currentPrimeKeyboardType:SOFT systemPaddingBottom:-1
I/NormalModeController: NormalModeController.getKeyboardBodyViewHolderPaddingBottom():114 currentPrimeKeyboardType:SOFT systemPaddingBottom:-1
So android itself is not detecting that gboard suggestions bar is showing.
Edit:
The insets.getInsets(Type.ime()).bottom
value doesn't change either.
Edit2:
The above logcat
entries are from Gboard, not android os.
Someone emailed similar case for SwiftKey where number row was covering terminal.
There is a similar report about this here, but extra keys work differently.
The hack that I can think of to make this work could to be to allow user to add terminal-bottom-margin
to termux.properties
which will be used to always show some space below extra keys and terminal. I guess a key could be added to extra keys to toggle this, so that user for whom this only happens when copying text can do it temporarily while gboard shows the suggestion, and toggle it again when it doesn't. I currently hardcoded this by adding android:layout_marginBottom="40dp"
to root RelativeLayout
of activity_termux.xml
, but this should be configurable dynamically. Maybe there is a better way, android views are not my thing.
So I did some more testing. On Android 11 avd, the clipboard suggestion bar don't show when text is copied
Dit you do version 10.5.03.367007960-release-x86` update? I did it here on a Pixel-4 AVD with Android 10 and then get the overlapping extra row (after Copy above):
After Paste, BACK
and KEYBOARD
key I get:
Before of Paste I have replaced clipboard with an alternative text. The workaround has corrected (remove extra line) this again. However, sometimes I get google Restarts or KEYBOARD
must press several times.
The clipboard text in the extra line is sometimes changed and sometimes not. The property: enforce-char-based-input=false
does not change the behavior. The option "Turn off the Extra line without replacement" (hold in mind) would like me.
So Gboard issue should be fixed with e7dd0eee. I have tested it on android 7 device and android 10 and 11 avd. For android 11 avd, I had to clear Gboard's app data for new UI to load properly. Moreover, for bug to occur, you also need to enable number keys row toggle to be enabled in gboard settings in addition to clipboard suggestions toggle.
I am not sure if this will fix issues with other keyboards, but hopefully should do it since solution used is kinda generic and will work with and without enforce-char-based-input
enabled. If this causes some problems, like infinite loop or something of margin adjustments, let me know. Redraws of terminal view are expected in some cases. Check TermuxActivityRootView javadocs for the details. It also clears some inaccuracies in my above comment.
New release is planned to be released today if no bugs come in.
Thanks! I've checked on my Pixel_2_API_30.avd
. Complete reset was needet (stalled 2 h work/wait) and gboard update. I get:
Aditional to this (arch=i686) I've installed on my Gigaset (arch=arm) and get: On both devices your last master update (version 114 I've extendet) are installed and the boot-loop update was done. I continue with OS-KB check. The gboard bug is solved and this issue could be closed!
Thanks for the confirmation. Would be good to have swiftkey number rows solved as well.
The gboard bug is solved and this issue could be closed!
This issue is not related to overlap issue. Overlap is (also) reported in #538
Would be good to have swiftkey number rows solved as well.
If above the extra key line is missing, the problem is already solved in v113. In the following shot (horizontal split), next to the Swift-KB, Termux (left) with the Extra Key line and X11 (right) _with its Extra Keys (not in vertical position) can be seen - without overlaps.
It could also be a device specific issue so not sure yet. And e7dd0ee should work even if extra keys are enabled or not.
This bug appears me after type "apt upgrade" using the app from Google Play(is not the last version), so I uninstall it and install the Fdroid version 0.117 but the bug still persist. I solve this changing the idiom of gboard from multilingual(English / Spanish) to Spanish or English. I'm using a Redmi C3 and use Android 11.
So I managed to reproduce the issue too. It doesn't happen in all multilingual languages including Norwegian.
It does happen with Chinese Traditional language, when you open termux with it selected, the keyboard space bars literally says QWERTY
instead of the Chinese language symbols. The value for enforce-char-based-input
does not affect this, so I wonder how chinese people type passwords in chinese if gboard switches to QWERTY
mode with InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS
. The value for Suggest English words
which would likely be equivalent to Multilingual typing
toggle for some other languages does not affect it either. I only tested on Android 7 though.
Also found a termux bug where if in text input view mode and chinese was showing properly and I switch to another app and come back to termux which would still start in text input view mode, the QWERTY
keyboard was loaded. That should be fixed by 2b7aa5e.
As for fixing the forced QWERTY
issue, that seems to be an issue with Gboard and not termux, although chinese does show with InputType.TYPE_TEXT_VARIATION_URI
but that has the issue of characters not showing until space is pressed. It should be reported to Gboard support for fixing since we need correct behaviour with InputType.TYPE_NULL
.
Problem description when gboard input method is used with termux, only ascii keyboard can be used.
Steps to reproduce Install google gboard keyboard, and use it with termux
Expected behavior
Additional information never worked with any version of termux