auto toggle toolbar when suggestions are available #674

codokie · 2024-04-11T13:29:15Z

I added a new setting that makes the suggestions appear automatically as they become available without having to touch the expand toolbar key. If there is no character before the cursor (when starting input or after a newline), the main toolbar will be shown. This functionality is present in many other mainstream keyboards. I believe this fixes #449
Here is a short demo

toolbar.mp4

HoroTW · 2024-04-23T20:22:30Z

I was about to open a feature request for exactly that!
I use voice input a lot (with FUTO Voice - open / local on-device voice input) and so it was annoying to always click an unnecessary button 😅 at least annoying enough for me to go through all the settings multiple times 😂.

Thanks for the PR, I will look through it/test it and give feedback in the next days! 👍🏻

better summary wording

codokie · 2024-04-23T23:17:34Z

no problem glad you liked it 👍
I updated it to show the toolbar when the suggested words are empty, i believe that would be more useful.
Feedback would be great!
P.S for your use case you can also pin the voice key for easy access

Helium314 · 2024-05-12T18:13:32Z

Could you also add a separate settings for just auto-hiding the toolbar when suggestions are available?

When you have pinned keys, they will flash when you type e.g. .... This needs to be fixed.

app/src/main/java/helium314/keyboard/latin/LatinIME.java

Helium314 · 2024-05-13T17:18:12Z

When there are default suggestions on opening an input field (with next-word-suggestions on), the toolbar shortly shows up, and then disappears once the suggestions arrive.
Selecting text by long pressing on text and moving the marker, the pinned keys flash on every move.
When trying to move through the text using left/right keys on toolbar, you can only do so until the first suggestions appears (auto-hide setting would help here).

codokie · 2024-05-18T21:11:21Z

@Helium314 thanks for the feedback and sorry about the delay

When trying to move through the text using left/right keys on toolbar, you can only do so until the first suggestions appears (auto-hide setting would help here).

I have divided the toggle setting to 2 separate settings (show/hide),
Now the toolbar will be shown if one of the following conditions is met:

there is a selection of text
it's the start of a line
on input start if the cursor does not touch a word.
when all visible suggestions were manually deleted

That should help those who use pinned navigation toolbar keys, it was a bit too intrusive to show the toolbar after each word.

When there are default suggestions on opening an input field (with next-word-suggestions on), the toolbar shortly shows up, and then disappears once the suggestions arrive.

Could u please check if this is still an issue, my device may render it too fast for me to notice the flicker

Helium314 · 2024-05-19T20:37:38Z

sorry about the delay

There is really no need for that, here I'm much worse...

Could u please check if this is still an issue, my device may render it too fast for me to notice the flicker

Yes, it still happens

codokie · 2024-05-20T09:06:42Z

Do you happen to know whether this piece of code is necessary?
If for some reason the visibility of the toolbar container needs to be set to GONE whenever the keyboard window is hidden, then I'm afraid there is no way around this flicker

Helium314 · 2024-05-22T21:52:24Z

It was added in e337f74.
So it doesn't need to be set to gone, but at least that should be an option (that's what I mentioned with "happens curently" in #449 (comment))

codokie · 2024-05-26T09:44:17Z

Ok so I modified the condition in hideWindow() so the visibility of the toolbar is set to GONE only if the "auto show toolbar" setting is not enabled.
I can't seem to reproduce the bug described in #185 when that setting is enabled, maybe that fix is not needed anymore?

I believe the flickering should be mostly gone (hopefully) with 92d7827, would appreciate a feedback to know if it's still present.
I debugged some edge cases and it seems to work as intended.

Helium314 · 2024-05-26T16:08:34Z

Flickering looks mostly good now. There are a few more cases where it happens, like when the toolbar was showing, you close the keyboard, and then tap inside some text field where toolbar should not show. But that's more obscure, and not necessary to fix.
(with next word suggestions on, when set to off the toolbar is not auto-showing at all)

One think I noticed when re-reading:
This does not show the tool bar when opening an input field and there are suggestions, which is requested in #449.
Could be done by adding something like

                boolean suppressResume = currentSettingsValues.mAutoShowToolbar
                        && mInputLogic.mConnection.getTextAfterCursor(1, 0).length() == 0
                        && mInputLogic.mConnection.getCodePointBeforeCursor() == Constants.NOT_A_CODE;
                if (!suppressResume)
                    mHandler.postResumeSuggestions(true /* shouldDelay */);

right above the first needToCallLoadKeyboardLater = false;, i.e. don't try getting suggestions when the input field is empty and mAutoShowToolbar is on.

codokie · 2024-05-26T18:59:34Z

@Helium314 thanks a lot for the feedback

This does not show the tool bar when opening an input field and there are suggestions

Yeah I've noticed that too, I just wasn't convinced that the toolbar should be displayed in that case.

Note that the suggestions are shown only when the "Personalized suggestions" setting is enabled because they are actually personalized predictions. So if that setting is turned off, the main toolbar will be shown.

I can add the provided code, but then personalized predictions won't be suggested when the input starts.

Also, upon reading the comment above the first needToCallLoadKeyboardLater = false;, it seems like it might not be right to depend on the return values of functions that use the position of a "lying" cursor

Helium314 · 2024-05-26T20:10:02Z

I can add the provided code, but then personalized predictions won't be suggested when the input starts.

I think it makes sense to also show it in this case, because (at least for me) those initial suggestions are rarely something I actually want to type.
But no matter which way we do it, it's simple to switch.

it seems like it might not be right to depend on the return values of functions that use the position of a "lying" cursor

The code above essentially checks whether the text field is empty, which does not depend on the cursor position. (maybe that could be checked more efficiently)

Helium314 · 2024-05-27T16:27:22Z

A summary when the toolbar shows automatically, depending on other settings (auto-show and auto-hide enabled)

next word & personalized suggestions enabled
- in non-text input fields
- after enter in multi-line field, except when having pressed delete right before (because suggestions show up inconsistently)
- when clicking to a place where suggestions for empty previous word are shown, and then entering e.g. .
  - not when entering e.g. and / or . when initially touching a word (suggestions are shown after , but go away after .)
next word suggestions enabled, personalized suggestions disabled
- in non-text input fields
- when text input field is empty
- after enter in multi-line field
- when clicking to a place where no suggestions are shown, and then after entering e.g. or .
  - not when entering e.g. or . after a word (no suggestions are shown though)
next word suggestions disabled or suggestions disabled
- never

codokie · 2024-05-28T20:02:44Z

Thanks for the detailed summary. I assume it is an observation of the current behavior? because I don't think that all of it is intended.
The consistency of the personalized suggestions should be improved but probably not as part of this PR. Such suggestions are only shown when it's the beginning of a new sentence for some reason.

In my opinion the toolbar should be auto shown when:

It's the beginning of a line and only neutral suggestions are available
Input starts, even if the input field is not empty, as long as cursor does not touch word
All suggestions were manually removed
Text is selected

The toolbar should be auto-hidden when actual suggestions are available (including inline suggestions)

If suggestions are disabled, I think the "auto show toolbar" setting is still useful & should not be affected (the suggestion strip view is of no use in that case, and should probably be disabled, but that is another issue)

On a side note, it seems like a waste of screen estate that setNeutralSuggestions() sets empty suggestions if next-word suggestions are disabled. Do you think it would be possible to show the top 3 dictionary words with highest frequency instead?

Helium314 · 2024-05-28T21:27:20Z

Thanks for the detailed summary. I assume it is an observation of the current behavior? because I don't think that all of it is intended.

I wasn't sure whether everything was working as you intended, that's why I wrote the summary.

It's the beginning of a line and only neutral suggestions are available

👍

Input starts, even if the input field is not empty, as long as cursor does not touch word

Not sure about the "even if the input field is not empty" part, but at least some uses will want this.

All suggestions were manually removed

This seems to be a very specific and rare situation. It should only be considered if it doesn't introduce much complexity.

Text is selected

👍

The toolbar should be auto-hidden when actual suggestions are available (including inline suggestions)

I think hiding words properly already, didn't test inline suggestions though.

On a side note, it seems like a waste of screen estate that setNeutralSuggestions() sets empty suggestions if next-word suggestions are disabled. Do you think it would be possible to show the top 3 dictionary words with highest frequency instead?

Possible yes, but it might not be particularly useful (and then the app is showing next-word suggestions despite the setting being disabled).

codokie · 2024-05-28T22:03:37Z

that's why I wrote the summary.

thanks, it was helpful!

It should only be considered if it doesn't introduce much complexity.

it's a relatively simple check, currently that's not a common situation but it may be useful in the future when dismissing clipboard suggestions

Not sure about the "even if the input field is not empty" part,

I personally find it quite useful to have an accessible toolbar when I start writing in an input field and then need to copy-paste some text from somewhere else.

(and then the app is showing next-word suggestions despite the setting being disabled).

My bad, what I meant was that empty suggestions are shown when next-word suggestions setting is enabled.
When next-word suggestions are disabled, setNeutralSuggestions() shows punctuation suggestions, which are more useful than the empty suggestions.

Helium314 · 2024-05-30T08:51:00Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

@@ -1144,7 +1154,7 @@ public void onExtractedCursorMovement(final int dx, final int dy) {

    @Override
    public void hideWindow() {
-        if (mSuggestionStripView != null)
+        if (mSuggestionStripView != null && !mSettings.getCurrent().mAutoShowToolbar)


Could you add some comment to the code on why hiding the toolbar depends on the auto-show setting? When reading just the code here, and not the entire PR one could easily assume it's a mistake.

Actually it does not seem like a good idea to hide the toolbar only if the auto show setting is disabled if the reason for hiding the toolbar is #185.
Maybe it would be better to test whether it is possible to not hide the toolbar at all in hideWindow()?

Why did you remove it? I just would have liked a comment in the code to avoid confusion, but now I am confused with this change...

because I don't seem to replicate #185 which was the reasoning for adding it, was it not?
if you can, please check whether the bug is still there. I don't think that line should have been added in the first place..
it causes flickering on input start when auto showing the toolbar, and it does not make sense not to execute a bug prevention code just because some setting isn't disabled.

Helium314 · 2024-05-30T08:59:15Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

+            // Auto hide the toolbar if dictionary suggestions are available
+            if (currentSettingsValues.mAutoHideToolbar
+                    && !noSuggestionsFromDictionaries
+                    && !suggestedWords.isPrediction()) {


Why don't hide if it's a prediction?

because it would conflict with auto show on input start.
I could change it to this so predictions will auto hide the toolbar if the auto show setting is disabled:

if (currentSettingsValues.mAutoHideToolbar && !noSuggestionsFromDictionaries && (!suggestedWords.isPrediction() || !currentSettingsValues.mAutoShowToolbar)) {

I just wanted to know why you added it like this, it was not a criticism or request for change.

Now you changed it to (!suggestedWords.isPrediction() || !currentSettingsValues.mAutoShowToolbar)) {, but I'm still not sure I understand why. (and really, this is not a request to change it, just for clarification)

Actually never mind, it seems predictions are not actually generated on input start, not sure why I thought they did.
I can simplify the condition to

if (currentSettingsValues.mAutoHideToolbar && !noSuggestionsFromDictionaries)

which should auto hide the toolbar when predictions are available

app/src/main/java/helium314/keyboard/latin/settings/CorrectionSettingsFragment.java

app/src/main/res/values/strings.xml

codokie

@Helium314 feee2f2 is 100% going to cause a flicker on input start every time..
if you really think this is needed then you might to implement this function:

@Override
    public void showWindow(boolean showInput) {
        if (mSuggestionStripView != null && mSettings.getCurrent().mAutoShowToolbar)
            mSuggestionStripView.setToolbarVisibility(true);
        super.showWindow(showInput);
    }

so that the toolbar visibility will be set ASAP, likely before the someone could notice it

codokie · 2024-05-18T21:11:29Z

app/src/main/java/helium314/keyboard/latin/suggestions/SuggestionStripView.java

@@ -256,7 +256,7 @@ private void updateKeys() {
                ? km.isDeviceLocked()
                : km.isKeyguardLocked();
        mToolbarExpandKey.setOnClickListener(hideToolbarKeys ? null : this);
-        mPinnedKeys.setVisibility(hideToolbarKeys ? GONE : VISIBLE);
+        mPinnedKeys.setVisibility(hideToolbarKeys ? GONE : mSuggestionsStrip.getVisibility());


Selecting text by long pressing on text and moving the marker, the pinned keys flash on every move

Nice catch. I believe this change should fix it ^

codokie · 2024-05-26T09:51:51Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

+            }
+        } else if (currentSettingsValues.mAutoShowToolbar) {
+            final int codePoint = mInputLogic.mConnection.getCodePointBeforeCursor();
+            if (mInputLogic.mLastComposedWord == LastComposedWord.NOT_A_COMPOSED_WORD


It's a little tricky to auto show the toolbar on input start without causing a flicker, so I converted that requirement to this check every time an empty suggestion is about to be shown.
From my observation, the side effect is that now the main toolbar may also be shown when the cursor is moved to a position in which the previous word is not a valid word

I think this condition is problematic so it's going to be removed:
if (mInputLogic.mLastComposedWord == LastComposedWord.NOT_A_COMPOSED_WORD
it does not seem to work as expected for my use case, which is to show the toolbar if the user hasn't typed anything yet in the input field.
It's because whenever a word is deleted, the last composed word is also affected as a result, which wasn't my intention.

codokie · 2024-05-30T10:48:54Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

+            // Auto hide the toolbar if dictionary suggestions are available
+            if (currentSettingsValues.mAutoHideToolbar
+                    && !noSuggestionsFromDictionaries
+                    && !suggestedWords.isPrediction()) {


because it would conflict with auto show on input start.
I could change it to this so predictions will auto hide the toolbar if the auto show setting is disabled:

if (currentSettingsValues.mAutoHideToolbar && !noSuggestionsFromDictionaries && (!suggestedWords.isPrediction() || !currentSettingsValues.mAutoShowToolbar)) {

app/src/main/res/values/strings.xml

codokie · 2024-05-30T10:58:57Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

@@ -1144,7 +1154,7 @@ public void onExtractedCursorMovement(final int dx, final int dy) {

    @Override
    public void hideWindow() {
-        if (mSuggestionStripView != null)
+        if (mSuggestionStripView != null && !mSettings.getCurrent().mAutoShowToolbar)


Actually it does not seem like a good idea to hide the toolbar only if the auto show setting is disabled if the reason for hiding the toolbar is #185.
Maybe it would be better to test whether it is possible to not hide the toolbar at all in hideWindow()?

codokie · 2024-05-30T19:01:58Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

@@ -1144,7 +1154,7 @@ public void onExtractedCursorMovement(final int dx, final int dy) {

    @Override
    public void hideWindow() {
-        if (mSuggestionStripView != null)
+        if (mSuggestionStripView != null && !mSettings.getCurrent().mAutoShowToolbar)


because I don't seem to replicate #185 which was the reasoning for adding it, was it not?
if you can, please check whether the bug is still there. I don't think that line should have been added in the first place..
it causes flickering on input start when auto showing the toolbar, and it does not make sense not to execute a bug prevention code just because some setting isn't disabled.

codokie · 2024-05-30T20:23:18Z

app/src/main/java/helium314/keyboard/latin/LatinIME.java

+            // Auto hide the toolbar if dictionary suggestions are available
+            if (currentSettingsValues.mAutoHideToolbar
+                    && !noSuggestionsFromDictionaries
+                    && !suggestedWords.isPrediction()) {


Actually never mind, it seems predictions are not actually generated on input start, not sure why I thought they did.
I can simplify the condition to

if (currentSettingsValues.mAutoHideToolbar && !noSuggestionsFromDictionaries)

which should auto hide the toolbar when predictions are available

BlackyHawky · 2024-06-01T13:40:36Z

Wouldn't it be better to have these settings in the new "Toolbar" page? 🤔

Helium314 · 2024-06-01T15:30:56Z

Wow. Sorry @codokie, GitHub didn't show me any of your comments from the past 2 days, only the pushes. So I was really confused first and then annoyed as it looked like you just pushed changes instead of answering my questions.
I'll look at it again...

Wouldn't it be better to have these settings in the new "Toolbar" page? 🤔

The toolbar settings don't exist in https://github.com/codokie/HeliBoard/tree/autotoggle-toolbar, but the plan to move the settings should be somewhere in here.

Helium314 · 2024-06-01T20:12:43Z

feee2f2 is 100% going to cause a flicker on input start every time..

Under which conditions? I tried a quite a few different things, but never managed to get that flicker..

codokie · 2024-06-01T20:56:28Z

Sorry @codokie, GitHub didn't show me any of your comments from the past 2 days

No worries I had a feeling Github notifications may be broken. Thanks for merging my PR

Under which conditions? I tried a quite a few different things, but never managed to get that flicker..

You know what, never mind, I think most people won't be able to notice it unless their phone lags.
I remember it being the main suspect for the previously reported flickering, but it might have been a conflict with the condition of the auto hide.

codokie added 2 commits April 11, 2024 16:15

auto toggle toolbar when suggestions are available

a625c3c

change problematic condition

efccbc2

codokie and others added 2 commits April 24, 2024 02:10

show toolbar when suggested words is empty

4c8ef79

better summary wording

Merge branch 'Helium314:main' into autotoggle-toolbar

39f9a0c

codokie mentioned this pull request Apr 25, 2024

Push toolbar keys to the end of the container #753

Closed

Helium314 reviewed May 12, 2024

View reviewed changes

app/src/main/java/helium314/keyboard/latin/LatinIME.java Outdated Show resolved Hide resolved

codokie added 3 commits May 18, 2024 18:13

Merge branch 'main' into autotoggle-toolbar

eb2be3f

fix toolbar flicker and split toggle to 2 settings (show/hide)

01112c2

auto show toolbar when all suggestions were removed

4c667ae

codokie added 2 commits May 26, 2024 12:26

Merge branch 'main' into autotoggle-toolbar

429ec62

another attempt to fix the flickering

92d7827

codokie added 2 commits May 28, 2024 22:43

refine conditions to show toolbar on input start

5a78787

auto show toolbar when suggestions are disabled

5d8de9c

update summary, add missing null check, etc.

17b1aea

Helium314 reviewed May 30, 2024

View reviewed changes

app/src/main/java/helium314/keyboard/latin/settings/CorrectionSettingsFragment.java Outdated Show resolved Hide resolved

Helium314 reviewed May 30, 2024

View reviewed changes

app/src/main/res/values/strings.xml Outdated Show resolved Hide resolved

codokie added 3 commits May 30, 2024 14:08

another summary update, adjust hide condition for prediction, etc.

68ee485

don't hide toolbar on hideWindow

4ca4a75

auto hide the toolbar when predictions are available

59f5ffc

codokie referenced this pull request in codokie/HeliBoard May 31, 2024

adapt last commit dc4755b to Helium314#688

12cddf4

Helium314 and others added 2 commits June 1, 2024 14:00

Merge branch 'main' into autotoggle-toolbar

70daa03

this is not going to be removed without a comment

feee2f2

Helium314 merged commit b9451e4 into Helium314:main Jun 1, 2024
1 check passed

codokie commented Jun 1, 2024

View reviewed changes

This was referenced Jun 1, 2024

Lock clipboard history view if device is locked #828

Open

Hide expand button when all toolbar buttons are pinned #732

Open

codokie deleted the autotoggle-toolbar branch June 4, 2024 20:27

Helium314 mentioned this pull request Jun 22, 2024

Always show toolbar #769

Closed

codokie mentioned this pull request Jul 14, 2024

improve inline suggestions #675

Draft

auto toggle toolbar when suggestions are available #674

auto toggle toolbar when suggestions are available #674

Conversation

codokie commented Apr 11, 2024

HoroTW commented Apr 23, 2024

codokie commented Apr 23, 2024

Helium314 commented May 12, 2024

Helium314 commented May 13, 2024

codokie commented May 18, 2024 • edited Loading

Helium314 commented May 19, 2024

codokie commented May 20, 2024

Helium314 commented May 22, 2024

codokie commented May 26, 2024

Helium314 commented May 26, 2024

codokie commented May 26, 2024

Helium314 commented May 26, 2024

Helium314 commented May 27, 2024

codokie commented May 28, 2024

Helium314 commented May 28, 2024

codokie commented May 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codokie left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BlackyHawky commented Jun 1, 2024

Helium314 commented Jun 1, 2024 • edited Loading

Helium314 commented Jun 1, 2024

codokie commented Jun 1, 2024 • edited Loading

codokie commented May 18, 2024 •

edited

Loading

codokie left a comment •

edited

Loading

Helium314 commented Jun 1, 2024 •

edited

Loading

codokie commented Jun 1, 2024 •

edited

Loading