Add emoji search

[eranl]

Added a search key to the emoji bottom row. When pressed, if an emoji dictionary for the current language is found, the emoji search activity is launched; otherwise, the settings screen is opened. This is a placeholder for taking the user to the dictionary settings screen, for them to add a dictionary. Should we hide the search button if there's no dictionary instead?
The emoji search activity is displayed in a gap created for it above the keyboard and below the host app using privateImeOptions, and partly obscures the host app. The suggestion/toolbar strip is hidden in this mode.
If the user presses an emoji, the search is finished, in order to insert that emoji into the host app's edit box.
If the user presses the done action button and autocorrect is on, the first suggested emoji is inserted the same way.
As a follow-up, we can change the action button to search, which when pressed, will close the activity, and open a special emoji keyboard containing the search results, which will allow the user to insert multiple emojis.
If the user switches to emoji view or clipboard view during search, the search is aborted. Should we hide these buttons instead?
If the user switches to an unsupported language during search, the search is aborted.
When the activity is stopped, it passes its results to LatinIME.
Fixed emoji descriptions on the emoji keyboard in the case of a Default emoji skin tone setting.

Styling of the title bar and edit box is not done, and I'm not sure how to do it. Heliboard's color system seems to be incompatible with Compose.
Moved the emoji row count -> max key count calculation into DynamicGridKeyboard. As a side effect, also changed config_emoji_keyboard_max_recents_key_count to config_emoji_keyboard_max_recents_row_count. Wasn't sure what values to use there though. If this part is not desired, I'll revert.
Had to use a Compose beta version, in order to get this fix.
Copied SingleDictionaryFacilitator & SuggestionResults changes from #1660.
Displaying the right emojis in the case of a Default emoji skin tone setting should probably be applied to #1660 and to normal emoji suggestions as well.
I used CloseIcon & SearchIcon from the settings package. Should generic compose code like Icons.kt be moved?

Fixes #259.

[maruuk]

Thank you very much for this feature! If I may, I'd like to suggest a few changes.

1. The search shouldn't close after selecting an emoji. The user may want to select more emojis or the same one multiple times.
2. After closing, the search should reset. It could display the emojis selected via search, rather than the last search result.
3. It would be ideal if a suggestion bar was displayed just like in Gboard.
4. Animations should be smoother. Keyboard reloading (which sometimes happens) should be eliminated.

[eranl]

Added some colors.

[eranl]

@maruuk, thanks for your feedback!

1. The search shouldn't close after selecting an emoji. The user may want to select more emojis or the same one multiple times.

I agree that this is a limitation of this implementation, but I couldn't find a good way around it, given that we have to close the activity in order to insert the emoji into the host app. This is why I suggested a follow-up improvement. Other ideas I considered and dropped:

• automatically reopening the search activity after entering an emoji - this seems too confusing
• adding another view for showing the selected emojis during search - seems like overkill

2. After closing, the search should reset. It could display the emojis selected via search, rather than the last search result.

This is a workaround for the above limitation. I wanted to make it as easy as possible to insert multiple emojis of the same search without retyping it.

3. It would be ideal if a suggestion bar was displayed just like in Gboard.

What do you mean by suggestion bar?

4. Animations should be smoother. Keyboard reloading (which sometimes happens) should be eliminated.

This is another consequence of the fact that I used an activity for the search.

[balintbarna]

Excited for this feature, thank you for your work! Do you have a screenshot of how it looks?

[maruuk]

@eranl I see. I hope you can figure this out with Helium's help. The ability to select multiple emojis is important to me, and certainly not only me. It would be best if we could quickly select emojis from search like in Gboard and FUTO.

What do you mean by suggestion bar?

The toolbar/word suggestion bar you mentioned is invisible in searches. I think it should be available, as it makes entering emoji names easier.

@balintbarna I have it. Out of curiosity I checked what it looks like.

As you can see, the search bar color doesn't quite match the accent color. In my opinion, the entire search appearance should match the keyboard background color, in my case gray. It would be nicer, and the search text would be more visible.

It works quite well, but it needs tweaking. The whole thing should definitely be smoother. Sometimes the search opens but then closes.

The dictionaries also need to be adjusted, as they're currently suggesting strange emojis, but Helium said he could look into that.

[eranl]

The ability to select multiple emojis is important to me, and certainly not only me. It would be best if we could quickly select emojis from search like in Gboard and FUTO.

Totally agreed.
Some technical background: putting a search box inside the keyboard has potential issues that we're concerned about. Even Gboard seems to have such issues. So the activity approach seems safer. And the follow-up improvement I proposed may fill the gap.

The toolbar/word suggestion bar you mentioned is invisible in searches. I think it should be available, as it makes entering emoji names easier.

I think that might be confusing, and not that helpful, as search input would likely be short. But I don't have a strong opinion here.

As you can see, the search bar color doesn't quite match the accent color. In my opinion, the entire search appearance should match the keyboard background color, in my case gray. It would be nicer, and the "search" text would be more visible.

I don't have an opinion about which colors to use. I chose the functional key colors just to make the search box noticeable, but I'm happy to change to anything else. Was your screenshot taken with latest code? For some reason it looks different from the functional keys.

Sometimes the search opens but then closes.

I would love to get more details, so I can fix it. I did encounter such bugs, and fixed them. Did you try the latest code?

The dictionaries also need to be adjusted, as they're currently suggesting strange emojis, but Helium said he could look into that.

Are you using a new dictionary? Again, I would love to hear about specific issues, so I can fix them. We've iterated quite a bit on these dictionaries, but issues are certainly possible.

[balintbarna]

Thank you again for your work. I just tried gboard for comparison and it seems like it does everything quite well: search doesn't disappear, can insert multiple emojis, word suggestions are visible. And many other nice features. The design also fits together quite well.

[maruuk]

As a follow-up, we can change the action button to search, which when pressed, will close the activity, and open a special emoji keyboard containing the search results, which will allow the user to insert multiple emojis.

You mean this workaround?

I think that might be confusing, and not that helpful, as search input would likely be short. But I don't have a strong opinion here.

In my opinion, it might be useful. Today, while testing, I typed "keyvoard" instead of "keyboard" and didn't get the correct emoji. The suggestion bar will let me choose the correct word, which will improve emoji suggestions. I remember this bar in Gboard speeding up typing emoji names.

Was your screenshot taken with latest code? For some reason it looks different from the functional keys.

Yes. I checked again more carefully, and it seems that this color doesn't adapt only to the "dynamic colors" theme. It adapts to built-in and custom themes and looks really nice.

I would love to get more details, so I can fix it. I did encounter such bugs, and fixed them. Did you try the latest code?

Yes. I only noticed this in a browser, e.g. Brave search or Google Translate. Sometimes it works, but after a few tries. In general, I have noticed that searching is most problematic in browser input fields, e.g. it opens slowly.

In the other apps, it doesn't close, but I noticed that sometimes it works faster and displays the search and keyboard at once, and other times you have to wait for one or the other. I know it's just a moment, but it would be visually nicer if the search and keyboard were displayed at the same time.

Are you using a new dictionary?

Ah, I was using the old one, I didn't know there was a new one. I checked and it's better, but it still suggests unrelated emojis, e.g. for "whale" it displays 🇵🇭🇹🇭🙀.

[eranl]

You mean this workaround?

It's not a workaround. It's a feature Gboard has too. I just think that adding it could alleviate the single-emoji issue.

Yes. I only noticed this in a browser, e.g. Brave search or Google Translate. Sometimes it works, but after a few tries. In general, I have noticed that searching is most problematic in browser input fields, e.g. it opens slowly.

Which browser do you use? I can't reproduce with FF or Chrome.

In the other apps, it doesn't close, but I noticed that sometimes it works faster and displays the search and keyboard at once, and other times you have to wait for one or the other.

You mean in all apps? What's your device/OS?

it still suggests unrelated emojis, e.g. for "whale" it displays 🇵🇭🇹🇭🙀.

The word whale has only two emojis linked to it, but the dictionary library is very "creative" in how it comes up with additional matches. Maybe we should set a score threshold.

[eranl]

Now the search activity sets hintLocales based on locales with emoji dictionaries, and emoji search is enabled regardless of the user's current locale, as long as they have any emoji dictionary.

[maruuk]

It's not a workaround. It's a feature Gboard has too. I just think that adding it could alleviate the single-emoji issue.

Got it. This will definitely be helpful, but users will probably ask why they can't select more emojis directly from search.

Which browser do you use?

Kiwi Browser, but I'll also check in IronFox.

What's your device/OS?

Motorola One Vision and Android 15 (LineageOS 22.2).

You mean in all apps?

I think so. Maybe it's because I'm using the debug version. It runs much slower than the release version.

The word whale has only two emojis linked to it, but the dictionary library is very "creative" in how it comes up with additional matches. Maybe we should set a score threshold.

In my opinion, only emojis whose name matches the search word should be displayed, like in Gboard. FUTO also suggests strange, unrelated emojis.

[eranl]

I think so. Maybe it's because I'm using the debug version. It runs much slower than the release version.

I also use the debug version, and haven't seen this.

In my opinion, only emojis whose name matches the search word should be displayed, like in Gboard.

The nice aspects of it are that it suggests emojis even when you partially type or mistype a word. BTW, have you tried searching with multiple words?

[maruuk]

I also use the debug version, and haven't seen this.

Hmm, I don't know what's wrong. If I close and reopen the search a few times, the animation sometimes speeds up.

BTW, have you tried searching with multiple words?

I checked and the suggested emojis are usually for the second word.

[eranl]

I checked and the suggested emojis are usually for the second word.

The order doesn't matter. It uses the average score against all words.

[Helium314]

This not good... but ok, then there's nothing we can do about it.

Unless we want to try the in-IME approach.

Possibly that needs to be done... but I'd say this is an improvement / overhaul for later. I took way too long with this PR, so let's hope people are ok with the experience.
And it's not like the're forced to use the emoji search anyway...

You could try something similar to the emoji key keyboard_state_selector.

Done. Did I do it correctly? The KeyboardStateSelector logic is tricky. It's a lot more code, but it looks better.

Look good, and feels "more correct" to me.

While testing, I realized that this code doesn't work (even if I export the receiver), so I added a NEW_DICTIONARY_INTENT_ACTION broadcast on dictionary deletion. Should we simplify DictionaryPackInstallBroadcastReceiver to just deal with a DICTIONARY_CHANGE_INTENT_ACTION?

I think that's because the DictionaryPackInstallBroadcastReceiver is meant for dictionaries that are installed as packages (apps), like it's done for AnySoft Keyboard. I don't know if that mechanism is in use for AOSP Keyboards at all...
The NEW_DICTIONARY_INTENT_ACTION is just using the receiver for internal dictionary changes.
(I'd say not sending an intent on dictionary delete is a bug, thanks for fixing)

[eranl]

Should we simplify DictionaryPackInstallBroadcastReceiver to just deal with a DICTIONARY_CHANGE_INTENT_ACTION?

I don't know if that mechanism is in use for AOSP Keyboards at all...

Should we clean this up then?

[Helium314]

I don't see a need to. Maybe at some point we find a use, or maybe the cleanup breaks other things (wouldn't be surprised...)

[eranl]

I used CloseIcon & SearchIcon from the settings package. Should generic compose code like Icons.kt be moved?

It's not absolutely necessary, but it makes sense.

I prefer doing this in a separate quick PR later, to avoid merge conflicts, as it touches many files.

Is now a good time to do this?

[eranl]

As a follow-up, we can change the action button to search, which when pressed, will close the activity, and open a special emoji keyboard containing the search results, which will allow the user to insert multiple emojis.

Should I go ahead with this?

[Helium314]

Is now a good time to do this?

Yes I think it's good.

Should I go ahead with this?

I don't know... it doesn't seem like a particularly convenient way to add multiple emojis.
Just leaving the search open (optionally via some setting) and caching the selected emojis to insert all at once is not an option?

[eranl]

Just leaving the search open (optionally via some setting) and caching the selected emojis to insert all at once is not an option?

How would I display the selected emojis during search?

[Helium314]

Just leaving the search open (optionally via some setting) and caching the selected emojis to insert all at once is not an option?

How would I display the selected emojis during search?

My first idea would be showing them in some Text composable. Or maybe a Row with one Text per added emoji, so the user can remove a single emoji with at tap.
I'm not sure though... does it make sense to you?

[eranl]

My first idea would be showing them in some Text composable. Or maybe a Row with one Text per added emoji, so the user can remove a single emoji with at tap. I'm not sure though... does it make sense to you?

I avoided such an additional view, because I thought it would be confusing. Where would you place it? My idea might also be confusing though...

[eranl]

Is now a good time to do this?

Yes I think it's good.

See #2327.

[Helium314]

My first idea would be showing them in some Text composable. Or maybe a Row with one Text per added emoji, so the user can remove a single emoji with at tap. I'm not sure though... does it make sense to you?

I avoided such an additional view, because I thought it would be confusing. Where would you place it? My idea might also be confusing though...

My first idea would be between the search results and the search input.
Or maybe after the "search emoji" text.

[robmonte]

I just want to say thank you so much for all the hard work on this feature!