Add emoji search #1765
Add emoji search #1765
Conversation
|
Thank you very much for this feature! If I may, I'd like to suggest a few changes.
|
|
Added some colors. |
|
@maruuk, thanks for your feedback!
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:
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.
What do you mean by suggestion bar?
This is another consequence of the fact that I used an activity for the search. |
|
Excited for this feature, thank you for your work! Do you have a screenshot of how it looks? |
|
@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.
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. |
Totally agreed.
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.
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.
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?
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. |
|
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. |
You mean this workaround?
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.
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.
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.
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 🇵🇭🇹🇭🙀. |
It's not a workaround. It's a feature Gboard has too. I just think that adding it could alleviate the single-emoji issue.
Which browser do you use? I can't reproduce with FF or Chrome.
You mean in all apps? What's your device/OS?
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. |
|
Now the search activity sets |
Got it. This will definitely be helpful, but users will probably ask why they can't select more emojis directly from search.
Kiwi Browser, but I'll also check in IronFox.
Motorola One Vision and Android 15 (LineageOS 22.2).
I think so. Maybe it's because I'm using the debug version. It runs much slower than the release version.
In my opinion, only emojis whose name matches the search word should be displayed, like in Gboard. FUTO also suggests strange, unrelated emojis. |
I also use the debug version, and haven't seen this.
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? |
Hmm, I don't know what's wrong. If I close and reopen the search a few times, the animation sometimes speeds up.
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. |
|
@eranl after way too long wait (and finally merging / very soon releasing 1660) I'll go over this. Catching up on the discussion and reading / testing may take a while, hope to be done with a first round this weekend. |
I would like to keep it consistent with other UI, but at the same time I'm not opposed. I'm one for functional styling, not for beautiful, so I'm probably the wrong person to ask. Anyway, how can I actually test it? When using the search button in all the apps I tested the screen flashes dark, then the keyboard goes away. Log, filtered for emoji: Finally to the initial questions (I guess some of them might not be relevant any more)
Yes, I think that makes sense
It's not absolutely necessary, but it makes sense.
I think you long found the solution, but at the same time it should be possible to add some compose-specific functionality.
I'm not sure I understand, possibly because I didn't yet test it. But isn't it good the user can abort the search?
Hmm, so the actual number of recent emojis might depend on device orientation now, because rows have different length in landscape and portait. That might be unexpected. |
# Conflicts: # app/src/main/java/helium314/keyboard/latin/LatinIME.java
Nothing useful here unfortunately. Can you please provide more of the log? |
|
Not sure what is different now, but it's working a little bit: when I press the search button the screen gets darker, the keyboard flashes and doesn't show the full log
To me it looks like the search is still active, and you can even start nested emoji searches (making the screen darker). |
|
Ah, now I see: when dismissing the keyboard during emoji seach, the search is shown at the bottom of the screen. Seems it's stuck at this position even if the keyboard is showing. |
The difference seems to be whether you have an emoji dictionary in the current locale. When the subtype auto-switches the search seems to be canceled. I can see the switched keyboard for a very short time. |
|
What's your device's API level? I was able to reproduce what you describe on an API 24 virtual device. Apparently, this implementation works on API 30+ only, since it relies on an implementation detail of |
|
One device API 29, one API 28. So you probably found the reason. |
|
Adding extra bottom padding to the main |
|
In the end, the fix was pretty simple... |
The thing is different configurations have different values, and they each seem to try to achieve a certain number of rows anyway. |
But the count only changes with Maybe we should rather have a fixed count instead. |
|
Looks like it works now, though not in landscape mode. |
You mean of emojis, right?
Fixed. Turns out the required API29- fix was even smaller than I thought.
I see the keyboard closing and reopening quickly. Is that what you mean? On the virtual devices, I also see the transparent/blank gap appearing first, and then the activity being shown in it. Haven't found a solution to either yet. |
Yes. Because the old (implicit) assumption of display having fixed smallest width doesn't hold any more. What do you intend with the change to rows?
Yes, you can see the area hidden by the keyboard for a short time. |
|
Even when keeping the keyboard always open (i.e. do nothin on |
…_keyboard_max_recents_row_count` change, adding two factory methods to `DynamicGridKeyboard`
Got it. Reverted. |
Done by disabling it. Is there a better way?
I prefer doing this in a separate quick PR later, to avoid merge conflicts, as it touches many files.
I think it would make sense to do that if and when there's another compose-based activity that requires this. |
|
Do you understand why the keyboard is disappearing for a short time when starting/switching activities? I didn't find anything to investigate it in inputView or latinIME where I'd assume you see what is happening.
You could try something similar to the emoji key
Agree. |
From my reading and testing, it appears that the system does that on every activity switch. It seems to be triggered by the search field getting focus.
It looks like I would need access to |
This not good... but ok, then there's nothing we can do about it.
For checking whether emoji dictionaries exist? Hmm, you could do the check in |
Unless we want to try the in-IME approach.
Done. Did I do it correctly? The While testing, I realized that this code doesn't work (even if I export the receiver), so I added a |
4 participants
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 changedconfig_emoji_keyboard_max_recents_key_counttoconfig_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&SuggestionResultschanges 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&SearchIconfrom thesettingspackage. Should genericcomposecode likeIcons.ktbe moved?Fixes #259.