Emoji Search

[D3SOX]

A search for emojis would be nice

[patrickgold]

Thanks for your suggestion. I guess you propose a search function similar to the one of GBoard, right? I'll add it to the todo list, probably for v0.4.0.

[heiwiper]

I would like to suggest an addition which I'm not sure it is directly related to this. It would be nice to have emojis suggested based on input but only if the user starts the word with a specific character, for example the user would type :<string> and the suggestiom bar would display emojis which their labels match <string>. This feature is similar to the one available on Discord and Anysoftkeyboard.

[D3SOX]

@HeiWiper Good idea! I think Gboard also has this when you type the exact emoji name (e.g. cat) and it suggests 🐈 Definitely related but I also think it doesn't exactly fit in here. We could open another issue for this

[patrickgold]

@HeiWipe I like your idea a lot, but to keep things tidy, it would be best if you made a separate issue for this, as this issue is for an emoji search box within the media UI. Thanks!

[Sitavi]

I'm agree with that, would be really great to have this feature. That's why anysoftkeyboard have an advantage for me

[whitespacecode]

I'm agree with that, would be really great to have this feature. That's why anysoftkeyboard have an advantage for me

I just tried anysoftkeyboard, but i think in terms of emoji suggestion i still like swiftkeyboard the best. You can type anyting lik jo, be, ha -> normaly would be joy, beer, haha,... and you get a suggestion for a emoji.

[zeratax]

I would recommend to not do what discord and slack does and use some weird custom list for emoji short codes and names.

while unicode codepoint names suck, there is unicode cldr which gives keywords and names in many languages for every emoji. it's a great resource and not as confusing as a lot of the names currently used in e.g. slack (https://twitter.com/ArminderDahul/status/1030353691235241984)

http://cldr.unicode.org/translation/characters-emoji-symbols/short-names-and-keywords

[sabzo]

I know this feature will be implemented on 0.5.0 -- however if one wanted to experiment and add it what are practical steps?

I was able to add an EditText searchbox into smartbar.xml and editsmarbarview to show the searchbox. However when I attempt to type into the smarbarview searchbox the text is added to an input connection that is outside of the keyboard. I thought maybe the answer might be to check EditorInstance and try to force the input connection to focus on the smartbar view search box but I couldn't find a way to do so.

It's almost showing a keybaord within a keyboard -- or forcing an EditText in the MainArea of smartbarview to receive the textinput.

Any thoughts? @patrickgold @Glitchy-Tozier

[patrickgold]

I know this feature will be implemented on 0.5.0 -- however if one wanted to experiment and add it what are practical steps?

Well it is indeed tricky to have an edit text within the IME that is responsible for it. I'd suggest that the communication between the emoji edit text and the keyboard runs on an internal simulated input connection rather than trying to force the Android framework to focus on the edit text itself. 2 reasons for that:

1. If we force the focus away from the target app then we won't be able to re-focus it after the search without manual intervention by the user (I do not have the ability to give away focus from the keyboard, except when hiding the keyboard).
2. While the keyboard is showing for the internal edit text, a row of emojis is probably shown. Tapping on the suggested emojis should enter them into the target app rather than the edit text, so taking away the focus from the target app forcefully prevents us from doing that.

This means we have to kinda extend the EditText widget and allow for a "fake focus": When the user taps on the emoji search bar, the emoji edit text is visually prepped to look like it has focus and a cursor is also additionally rendered. When any character keystrokes or arrows, CTRL+V etc. is done, the emoji edit text receives this internally somehow - we could use a reference via the MediaManager and edit the characters manually for this or use Kotlin Co-routine Channels, or even implement a custom InputConnection - fact is, there are many ways to accomplish that. When an emoji is pressed however, it is processed normally and sent to the target app.

Intervention of sending keystrokes for the edit text should be done in the EditorInstance - this is where it makes most sense to me.

[Glitchy-Tozier]

Any thoughts? @patrickgold @Glitchy-Tozier

Patrick is your guy for anything that is difficult, I'm not familiar enough with the code of the app

[sabzo]

I know this feature will be implemented on 0.5.0 -- however if one wanted to experiment and add it what are practical steps?

Well it is indeed tricky to have an edit text within the IME that is responsible for it. I'd suggest that the communication between the emoji edit text and the keyboard runs on an internal simulated input connection rather than trying to force the Android framework to focus on the edit text itself. 2 reasons for that:

1. If we force the focus away from the target app then we won't be able to re-focus it after the search without manual intervention by the user (I do not have the ability to give away focus from the keyboard, except when hiding the keyboard).

2. While the keyboard is showing for the internal edit text, a row of emojis is probably shown. Tapping on the suggested emojis should enter them into the target app rather than the edit text, so taking away the focus from the target app forcefully prevents us from doing that.

This means we have to kinda extend the EditText widget and allow for a "fake focus": When the user taps on the emoji search bar, the emoji edit text is visually prepped to look like it has focus and a cursor is also additionally rendered. When any character keystrokes or arrows, CTRL+V etc. is done, the emoji edit text receives this internally somehow - we could use a reference via the MediaManager and edit the characters manually for this or use Kotlin Co-routine Channels, or even implement a custom InputConnection - fact is, there are many ways to accomplish that. When an emoji is pressed however, it is processed normally and sent to the target app.

This means we have to kinda extend the EditText widget and allow for a "fake focus": When the user taps on the emoji search bar, the emoji edit text is visually prepped to look like it has focus and a cursor is also additionally rendered. When any character keystrokes or arrows, CTRL+V etc. is done, the emoji edit text receives this internally somehow - we could use a reference via the MediaManager and edit the characters manually for this or use Kotlin Co-routine Channels, or even implement a custom InputConnection - fact is, there are many ways to accomplish that. When an emoji is pressed however, it is processed normally and sent to the target app.

Essentially it's mocking "edit text" functionality -- however it seems that you plan to redo the whole media component. So maybe I should wait for that phase? Or is the mocking code pretty independent from a future implementation?

[patrickgold]

Essentially it's mocking "edit text" functionality -- however it seems that you plan to redo the whole media component. So maybe I should wait for that phase? Or is the mocking code pretty independent from a future implementation?

The mocking itself is pretty independent, because the internal way of consuming key events and passing around things won't change that much in 0.5.0. The biggest conflict point is anything which has directly to do with the UI (layout xml or custom widget code), but I think if you make the EditText as independent from the current emoji UI as possible then it will be easy to integrate your UI code in 0.5.0's rework.

[codenyte]

Are there any updates on this? The issue was initially opened in Nov 2020, it's Apr 2023 and there is still no Emoji Search, which makes it a dealbreaker for me. I am forced to use proprietary Gboard and block internet connections using the Network permission toggle in GrapheneOS because no FOSS keyboard has this very simple feature of searching for emojis. None, neither the stock AOSP Keyboard shipped on GrapheneOS, OpenBoard, nor unfortunately FlorisBoard. Heck, if I was a little better at Java/Kotlin, I would code this shit myself if no one else is willing to do this, but my skill set unfortunately limits me in this regard. I really hope that this gets added to the otherwise amazing FOSS project soon.

[ghost]

Essentially it's mocking "edit text" functionality -- however it seems that you plan to redo the whole media component. So maybe I should wait for that phase? Or is the mocking code pretty independent from a future implementation?

The mocking itself is pretty independent, because the internal way of consuming key events and passing around things won't change that much in 0.5.0. The biggest conflict point is anything which has directly to do with the UI (layout xml or custom widget code), but I think if you make the EditText as independent from the current emoji UI as possible then it will be easy to integrate your UI code in 0.5.0's rework.

What i understood is the problem of having 2 cursor parallely running on 2 edit texts. Am i right?

I think the other way would be to read the last word typed by user on any edit text and suggest emoji based on it when tapped on emoji tab.

It would be like telegram suggesting stickers based on what last word typed🤔

[D3SOX]

Now that there are emoji name suggestions, this shouldn't be such a big effort