Add emoji button

[licaon-kter]

👍

[rkkr]

Emojis were removed intentionally and I don't plan to add them back. This is however made from AOSP project, so I might eventually distribute a vanilla AOSP keyboard which has them.

[wyjek]

That is a bummer, I need emojis and I would use AOSP keyboard, but I can't change its height.

[rkkr]

There is a hidden setting that you can probably set using adb. I have only exposed that setting in my fork.

[mvfsullivan]

Please please add this option. Maybe dont enable ot by default but have the option in Settings!!

[mimi89999]

Hello. I created https://github.com/mimi89999/aosp-keyboard-patches

[orogenic]

Seems like a lot of us want to use emojis with this keyboard. Can we implement it and place it behind either a runtime or buildtime feature flag so it's either toggled on/off in settings, or so we at least have a supported option to build with emojis enabled?

[licaon-kter]

Why not use OpenBoard then?

[orogenic]

Why not use OpenBoard then?

Why not integrate OpenBoard and Simple Keyboard under a set of buildtime and runtime options?

edit: while i do seriously want to see more integration and cooperation among software projects in general, taking advantage of sophisticated build and configuration systems to share more code and integrate designs where possible, my suggestion doesn't seem to make much sense. at least, i definitely didn't recall just how much larger openboard is than simple keyboard. idk why this is, i don't really know anything about the AOSP keyboard and how it relates to openboard and simple keyboard.

edit: as someone else pointed out the size difference is mainly due to font and dictionary files, and they do share the same codebase, so bugfixes and patches in one may be duplicated work in the other, so i'm back to thinking my suggestion is appropriate for someone who wants to see more cooperation and integration among software projects, especially two close forks of the same project.

[orogenic]

lmao i haven't even looked at openboard in quite a few months, my only comment is i think it recently changed substantially? and now it's a 40MB download for some reason? do you know? i think i used to not use it just cus i couldn't change the default background color or something. looks like that's not the case now, so idk what i'm remembering
edit:
edit: also i can't find the full list now but i also recall openboard having many many more permissions than simple keyboard. maybe that's no longer the case with their new update, tho i can still confirm F-Droid lists more permissions for openboard than simple keyboard. plus simple keyboard is still just a 862KB download. idk, i didn't think emojis would be a huge source of bloat because isn't all that provisioned by the operating system's fonts already? plus it'd provide an opportunity to implement something actually useful like keyword-based emoji search instead of what openboard provides which is just the default emoji layout, which takes quite a while to navigate.

[licaon-kter]

It's ok, it has the features everyone asks here: dictionaries and emojis.

Decide already, slim app or features.

[orogenic]

It's ok, it has the features everyone asks here: dictionaries and emojis.

that's a good reminder, thanks

Decide already, slim app or features.

are you implying these exclude each other? anyway i'd like both please :)

[mimi89999]

are you implying these exclude each other? anyway i'd like both please :)

@orogenic You can't get both. Just check the size of the Noto emoji font and of the dicts. They make most of the apk size and their size can't be reduced.

Why not integrate OpenBoard and Simple Keyboard under a set of buildtime and runtime options?

I think that having them as one repo with 2 flavors will be most practical. They are both based on the same code. They inherited the same bugs. Fixing a bug in one fork that has been fized in the other one will be duplicate work. Some features migh also benefit both.

[orogenic]

i didn't think emojis would be a huge source of bloat because isn't all that provisioned by the operating system's fonts already?

@orogenic You can't get both. Just check the size of the Noto emoji font and of the dicts. They make most of the apk size and their size can't be reduced.

that's a bummer. thanks for pointing that out

edit: i am also not sure i understand how my phone chooses the font it uses to display emojis. AOSP keyboard may be included with a distribution, and it has emojis. Just disabling it in settings and installing and using simple keyboard instead, which does not include emojis, my phone is still able to display emojis in many contexts. Some of those contexts I believe I'm aware the app provides its own emoji font, but I don't believe that is always the case. So, are other apps able to borrow emojis from the disabled AOSP keyboard? does the android system fonts really not provide emojis by default that simple keyboard could use... huh.

edit: even if simple keyboard cannot assume the system has emojis, i also think i've seen some F-Droid apps distribute separate installable plugins/components, so could that also be a strategy to provide a separate simple keyboard emoji download (also applies to dictionary files I guess), and leave it disabled by default in the main keyboard app?

edit: @mimi89999 i looked at your patch repo and it also made me think, if both the emoji and dictionary resources are provided by the base AOSP keyboard repo, it seems like a cool goal to maintain a repo where each of these features is sequestered away from the main keyboard using a strategy like the above with separate installable components, and to keep each patch as a well-separated commit rebased on top of AOSP. it sounds complicated, and like the patches could diverge with upstream AOSP keyboard releases, but idk. anyway I like your repo :)

I think that having them as one repo with 2 flavors will be most practical. They are both based on the same code. They inherited the same bugs. Fixing a bug in one fork that has been fized in the other one will be duplicate work. Some features migh also benefit both.

i did check after, so, they're both based on https://android.googlesource.com/platform/packages/inputmethods/LatinIME , good to know. anyway, do the core developers of simple keyboard and openboard communicate regularly with one another, do you happen to know? (i'll try and figure out more myself)

by "2 flavors", it appears to me "flavor" is a gradle term, so each flavor has different build options? sorry for this analogy, is there some analog to C macro conditionals, or what is the most straightforward way to include/exclude code at build time with gradle?

[RickyM7]

For those who want something more complete, opt for OpenBoard (https://github.com/dslul/openboard), it's basically Simple Keyboard with emojis and dictionary, and I imagine it will in the future have swipe-typing as well.
The v1.4.2 of this app that was recently released has no unnecessary permissions or anything like that.
It weighs 42MB on the F-Droid, that's basically what the Simple Keyboard would weigh if it had these functions, I think.
It makes no sense to keep asking for it here when what you want already exists.

[orogenic]

it's basically Simple Keyboard with emojis and dictionary

what you want already exists.

i do seriously want to see more integration and cooperation among software projects in general, taking advantage of sophisticated build and configuration systems to share more code and integrate designs where possible

Why not integrate OpenBoard and Simple Keyboard under a set of buildtime and runtime options?

I think that having them as one repo with 2 flavors will be most practical. They are both based on the same code. They inherited the same bugs. Fixing a bug in one fork that has been fized in the other one will be duplicate work. Some features migh also benefit both.

[RickyM7]

@orogenic I totally agree that having only one repo would be more practical and very beneficial for both projects for various reasons such as translations, bug fixes and mainly by decreasing the work of the devs that I imagine would occur by having all the contributors together.
Everyone would work on the overall project and then it would be compiled into two versions, the Lite Version: "Simple Keyboard" and the Full Version: "OpenBoard". That's what I imagined with your comments and I think that would be wonderful.
But since they are projects with different objectives, I think having separate repos is also plausible.

[ghost]

Why not use OpenBoard then?

Openboard doesn't run on boot but simpleboard does.

[rkkr]

Why not use OpenBoard then?

Openboard doesn't run on boot but simpleboard does.

File an issue for OpenBoard. They are welcome to copy daae07b.