-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Allow choice of Google/Android emoji's, like the Android app #975
Comments
duplicate of #194? |
No, 194 is about emoji entry, this is about emoji font display. |
Well, while there is no choice in the form of an option, you can navigate to
And then replace the files in there with emoji of your choice. |
@lucasjsmith Do you want the emoji to appear as Android style on the receiving end? I like the fact that Signal has standardized on one emoji set across Android, iOS, and Desktop. It eliminates ambiguity. |
@gordon-morehouse I would want it to act the same way as "Use system emoji" setting in the Android app, where it affects only the client where that setting is selected. Emoji ambiguity is a real thing, but users are accustomed to it happening in SMS and most chat apps, so it should be OK for it to be present in Signal. |
I would definitely love to see this |
I'm not sure we'll ever do this, since the current approach ensures that your emojis match what Android users (with default settings) and iOS users see. Maybe someone can talk about why this toggle is important? |
@scottnonnenberg Because quite frankly I (and many many others) find the iOS emoji repulsive and it's a matter of not homogenizing everything to the way that Apple sees it. That means that the client has an "Android"-themed UI layout and that would also include being able to switch away from the standard emoji set. People see different emoji implementations on different devices all the time, regardless of what messenger they use. It's not Signal's job to change that, especially since the Android client already has a switch to allow the system emoji to be used. So either a) provide the same switch, letting the Operating system decide what emoji font to use (which, on my Linux would be the Noto Android 8 emoji set but for people on Windows would be the Windows native set, etc) or b) Just hard-code in the Android emoji as an alternative. Generally the emoji support in the Signal desktop client is kinda bad. It doesn't seem to properly support all diversity modifiers or latest characters. This is clearly not a very high priority for the devs but I guess, consider this a case having been made in support of a toggle (and better support 😝) |
@spacekookie I'd love to see some examples of the problems you're having with emoji. Please file bugs when you run into that! Thanks for your perspective on the multiple emoji support. A couple challenges for that approach:
|
@scottnonnenberg The issues I've been having aren't bugs, they're expected behaviour because the Signal Desktop client doesn't support the later unicode specs (can't remember if it was 8, 9 or 10). But to test: 🏳️🌈 displays correctly pretty much everywhere on my system. In Signal desktop it splits it to "🏳️ 🌈" Regarding larger download sizes, I agree. As I said, there should be a toggle to allow a native system font to take over emoji support, same as on Android. Then it depends on the platform and whatever users have installed as their default emoji font. |
@spacekookie Signal Desktop (the standalone version) does support the latest Unicode release from May 2017 (Unicode 10 / Emoji 5). See: #1797 Have you installed the newest version? Just my two cents regarding showing Android emoji just for yourself. I think consistency is key. In my opinion it is not a good UX when emojis depend on various platforms and their adoption of the unicode standard and will be displayed differently on different devices. Since the same emojis look differently on Android/iOS/etc they often also lead to different interpretations of the emoji itself. It should be aimed for crossplatform consistency. At least then you know, the emoji you sent will be delivered as you have sent it. |
@rainerzufall I'm running Also…I think the point about consistency goes in the other direction as well. First, Android clients can use the system emoji to display. And you could argue for consistency on a platform: I want all my emoji to look the same and get annoyed when I see the ugly iOS ones in Signal. I already don't know if the recipient is going to see the Android one (because they're on Android), at least let me not see the iOS ones 😝 |
Personally, I prefer having emoji somewhat standardized across all versions of the app. I would rather see skin tone entry & display support added to all versions of Signal before seeing entire additional emoji sets added. There are also a large number of outstanding bugs in Signal Desktop, and other missing features, many of which would sit a lot higher in the priority queue to receive very limited developer resources before this one, if I were project manager. The annoying things for me about the Apple-style emoji support in Signal (Desktop and Android) are the lack of skin tone support, and the poor re-organization of emoji into their respective categories which came with the last update to Android. Thanks for soliciting user feedback on this, @scottnonnenberg. |
@spacekookie The latest beta version is |
@scottnonnenberg I installed it via the Arch Linux package on AUR. I've never seen a "new version available" pop-up. Although I've just seen that the package was updated so I'm updating the version now |
I installed the Linux app on my desktop, and was surprised to see Apple emoji, when my OS includes the open source, full color Noto Emoji. I was even more surprised when I went to the settings and did not see a toggle for native emoji support like there is in the Android app. Noto Emoji do an excellent job of reducing ambiguity while being more platform agnostic and fully open source. I would recommend Signal move to them across all platforms, but that's understandably a different conversation for a different issue. At the very least, allowing the use of the OS's native emoji (like on the Android app) would make sense. I could see an argument to have an option for Noto Emoji as an alternative to the Apple-style ones, but native emoji support would be acceptable as well. |
@cassidyjames It's highly unlikely that we'll support native emoji, since we support a lot of platforms (multiple versions of Windows, OSX, and many Linux distributions and window managers). More importantly, our goal is consistency of experience across the various apps. Sending or receiving a Signal message, no matter the client, should look the same. |
@scottnonnenberg-signal consistency goes both ways. Every other app, web page, and experience on my machine shares a consistent emoji set, as it's just a font. Signal sticks out by having closed-source, copyrighted Apple IP injected in my messages versus using the consistent platform emoji set. It's also a highly inconsistent stance; if "consistency of experience across the various apps" is truly the goal, then there wouldn't be an option in Android to use the device emoji, there wouldn't be different OS-specific themes and styling in the iOS and Android apps, etc. Consistency with the user's platform is extremely important, and by actively subverting that, you're making your app feel completely out of place and less native.
I don't know what window managers have to do with emoji, but okay. Windows and macOS have large sets of built-in emoji, and Linux distributions are moving in that direction. Using the same set across all apps may be an arguable default, but letting all users opt into using the device-provided emoji shouldn't add a large overhead at all. |
Thanks everyone for your input; we have all the information we need on this issue. In the future, the forums are for discussion, not issues like this: https://community.signalusers.org/ |
Please allow a setting to use Android-styled emojis, like there is in the Android app. The Desktop app allows the use of "Android" styling, and it should support following that look in this respect too.
The text was updated successfully, but these errors were encountered: