Closed Glitchy-Tozier closed 2 years ago
I would suggest less like an automatic saving than a preference in the Settings where you can select the default skin. I will add this to my todo-list, most likely will be implemented with the Emoji rework in v0.5.0.
What is your thought process behind preferring a general preference?
Having it as a general preference allows for a proper config to be exported when I implement Settings import/export. Also, I think that there may be cases where you don't have a preferred tone but just happened to choose one tone at the first time, and now this is the default even you didn't want to have it this way. This requires a field in the Settings to change this dynamically selected tone, so a general preference is just much easier to implement and less confusing.
What I was thinking was not making it the default permanently, but changing tbe default for teach emoji to whatever skin tone you used last.
Meaning that you could change it multiple times without ever oing into settings. (Basically, the way Whatsapp, Telegram and Signal do it)
However, if you want the user to set a global default, that also is an understandable decision. You choose.
I think the solution to this is to have a global list preference for skin tones with the values for the skin tones as well as an entry called Last used
. This way, it is the users decision if the skin tone should be globally set to a specific or if the skin tone should automatically be the last used.
Seems like a good idea. ππ»
So yesterday I experimented a bit with the "last used" but came to the conclusion that it is easier to implement to just have a "Preferred emoji skin tone" option in the settings (auto changing skin tones is a bit laggy and also confusing).
The implementation and its options aligns with other apps which offer this option (not that many apps even have the static option at all), having a dropdown with all skin tones available:
Be aware that this only works for emojis where the system font supports skins, if not FlorisBoard will use the default skin tone (yellow) as a fallback. Also the emoji history ignores the preferred skin tone and treats a waiving hand in default skin tone as another emoji that a waiving hand in light skin tone.
I hope that this still satisfies your proposal in the end, else we can finetune and improve the implementation of the preferred skin tone setting.
I'm fine with setting the preferred skin tone im settings. Saving themost recently used skin-tone for every emoji probably is more difficult for pretty much the same result.
auto changing skin tones is a bit laggy and also confusing
What do you mean? π€ (emoji typed with Florisboard :))
Also the emoji history ignores the preferred skin toneβ¦
Why? It seems to me like this might be the most important place to respect the preferred skin-tone. (This is important I think)
β¦and treats a waiving hand in default skin tone as another emoji that a waiving hand in light skin tone.
I understand you correctly in assing this is an example, right? You're not saying that the waiving hand emoji somehow has a different implementation?
What do you mean?Β π€Β (emoji typed with Florisboard :))
I meant if the emoji default skin tone changes as soon as an emoji was typed, it would create lag. As it is not implemented though it does run smooth (hopefully).
Why? It seems to me like this might be the most important place to respect the preferred skin-tone. (This is important I think)
This has to do with the way emojis are represented, e.g. ππ» and π have different code points. Without an table of emojis I can easily go from ππ» to π, because I can just remove the light skin tone. In the other direction I don't know though if the emoji supports skin tones or not and thus I cannot directly infer the skinned emoji.
Also both SwiftKey and Gboard also treat two different skin tones as different emojis in the emoji history. In my opinion with the time if you don't use a certain skin tone it will move down more and more in the emoji history until it gets removed according to the emoji history max size setting, so this shouldn't pose too much of a problem.
I understand you correctly in assing this is an example, right?
Yes, the wave is just an example to show off the skin tone. The setting applies to all emojis which have skin tones.
I meant if the emoji default skin tone changes as soon as an emoji was typed, it would create lag. As it is not implemented though it does run smooth (hopefully).
Im still slightly confused why something would lag in a situation like this β no heavy computation is performed and database-calls should be async
anyways β it doesn't matter though, because, as you said, the current implementation doesn't result in this lag anyways.
This has to do with the way emojis are represented, e.g. ππ» and wave have different code points. Without an table of emojis I can easily go from ππ» to wave, because I can just remove the light skin tone. In the other direction I don't know though if the emoji supports skin tones or not and thus I cannot directly infer the skinned emoji.
I probably initially misunderstood you. I thought what you said was typing "ππ»" would add ":wave:" to the most-recent-screen. What I think you're actually saying is that "ππ»" would add "ππ»", regardless of what the preferred skin color is. I agree with that implementation, it makes sense. :)
Also both SwiftKey and Gboardβ¦
Just a general heads-up: I think those two aren't what you should be looking at regarding emojies. I think what people use far more often are, in descending order:
The reason being that (I think) people preferably use the built-in solutions.
Yes, the wave is just an example to show off the skin tone. The setting applies to all emojis which have skin tones.
ππ»
I probably initially misunderstood you. I thought what you said was typing "ππ»" would add "wave" to the most-recent-screen. What I think you're actually saying is that "ππ»" would add "ππ»", regardless of what the preferred skin color is. I agree with that implementation, it makes sense. :)
:+1:
Just a general heads-up: I think those two aren't what you should be looking at regarding emojies.
I mean these two are fairly big keyboards and based on the complaints of people who missed the emoji palette in the last 6 or so beta releases emojis are needed outside of messengers internal solutions as well. I agree though that taking inspirations from messengers internal solutions can only help, so I will go over your list one by one:
WhatsApp uses a pretty common layout for the emoji palette, in which direction FlorisBoard mainly moves (although the search icon must be placed elsewhere for instance, because the space is already taken by return to the keyboard).
Telegram
Haven't used it, so can't say, same for any Facebook products
Discord
Combines all categories in one scrollable list (like Gboard too), and they need to integrate the server emojis. But it feels a bit clunky, so it will not serve that much of an inspiration, only the scrollable list is something I would like to see in FlorisBoard at some point.
Signal
Is a mix of WhatsApp, Discord and their own take on this topic. What I don't like is that the categories icons hide when scrolling, but on the other hand it creates more space for emojis to show. Also uses the category-overlapping list format.
Element
Basically what FlorisBoard in the latest beta has + the delete key is somehwere else. The thing I really like is there emoji auto suggest though via the :
colon and emoji name, that's one approach to integrate emoji suggestions, and an approach I've seen quite often tbh.
The reason being that (I think) people preferably use the built-in solutions.
That's true, especially when messengers use their own emoji styles.
Just a general heads-up: I think those two aren't what you should be looking at regarding emojies.
That phrasing was a little too extreme. what I meant was that messengers might be a better representation of th most commonly used emoji-board-designs.
Telegram
I'd prefer to not use it too, but currently my hand is being forced. If you want, I could send you screenshots. It's really nice, though nothing revolutionary.
Discord
I agree that it feels a little clunky. Just thought I should mention it, as it seems to be one of the frequently used "messengers".
The thing I really like is there emoji auto suggest though via the
:
colon and emoji name, that's one approach to integrate emoji suggestions, and an approach I've seen quite often tbh.
Yeah, it's kind of GitHub-like. I like the idea of adding this to the florisboard-suggestions. The important detail is to let the user search in any of the activated languages, not just the active one.
Make it so that the default skin-tones/variations of emojies get saved. This means that after inputting "π§π»ββοΈ" once, now the emoji typed by quickly typing on the icon should be "π§π»ββοΈ" and not "π§ββοΈ".
Of course that requires putting "π§ββοΈ" in the popup-options in that case. And displaying the new default instead on the emoji-keyboard.