New message view smiley bugs

[nurupo]

Here are some bugs/concerns from the new message view.

1. I noticed that smileys get updated when smileypacks changes, though I don't see anything from src/messages/ to listen for the Settings::smileyPackChanged signal.

Initially posted with the regular smiley pack.

Changed settings to the emoji smiley pack.

Anyway, I wonder if it's efficient enough to not cause freezes with many smiley messages, since some people apparently like keeping clients running for days.

Also, I noticed that most IM clients I know don't change the way smilies look like after they are sent, though this would be useful for "disable smilies" option.

2. When smilies updated or emoji font changed, the view doesn't update.

(moving one of column handles updates the view and fixes that).

3. Some regular smilies have emoji alternatives, so when sending a smiley image and then changing smiley pack to emoji, that sent smiley turns into emoji. Let's call them "emojified smilies", since they were originally smiley images that turned into emoji.

There seem to be a difference between regular emoji and emojified smilies. They both show emoji, but emojified smilies change their font size according to the one set in settings, when regular emoji don't (I would expect them to change their font size too, since smiley pack change updates how all smilies in the message view are displayed, so i would expect emoji font change to update the way emoji are displayed).

(the big :) were smiley images initially, the last two emoji are regular emoji)

4. Mixing smileys and emojis causes some bugs. For example, insert :) emoji, :) smiley and :) emoji again in the input widget and send them.

Here is the result with emoji pack on

And with smiley pack on

[23:22:11] Leah Twoskin: Middle one looks like OBJ inside a dotted rectangle

Since we ended on emoji, it looks like it didn't bother converting the smiley image object into ":)" on sending.

5.

As 3 says, font size setting doesn't affect font size of emoji we send (unless they initially were smiley images that turned into emoji as we changed the smiley pack to emoji), but apparently it affects the font size of received emoji. Font size setting affecting emoji size is actually the expected behavior, not a bug. The bug is that emoji we send aren't affected by the current font size setting or any changes, so this is kind of a duplicate of 3.

To fix those bugs I propose that smiley pack change or emoji font change:

• affects all smilies and emoji in the input widget, so that all smilies would be from the same smiley pack (i.e. desmilify the text with the old smiley pack and smilify it with the new smiley pack), and if emoji smiley pack is selected, all emoji would be of the same font. Fixes (4).
• affects all smilies and emoji in the message view. Fixes (3, 5).
• updates the message view layout. Fixes (2).

(1) is more of a concern of whether we should update already sent smilies or not, not a bug.

One thing that I wanted to check but didn't get to was copy-pasting an emoji while having regular smiley pack on. What I expect is if I insert an emoji and the current smiley pack is not set to replace it, the emoji font option would apply for the inserted emoji, i.e. it would be displayed with some special font. So the emoji font should probably be a separate (exclusive) option from the smileypack. Even if no smileypack is chosen, user might still want to see emoji in a different font.

So something like this would probably make sense:

--[ ] Enable smiley replacement------------------------
|                                                     |
|  ( ) Enable smiley replacement                      |
|      Smileypack: [smileypack name]                  |
|      Description: <description>                     |
|  ( ) Enable emoji replacement                       |
|      ( ) Send as emoji character                    |
|      ( ) Send as text representation                |
|                                                     |
|  Preview:                                           |
|  -------------------------------------------------  |
|  | Smiley image / Emoji | Text representation    |  |
|  -------------------------------------------------  |
|  | <image/emoji>        | <text representations> |  |
|  | <image/emoji>        | <text representations> |  |
|  | <image/emoji>        | <text representations> |  |
|  -------------------------------------------------  |
-------------------------------------------------------

-------------------------------------------------------
|  [ ] Enable emoji font change                       |
|  (Set emoji font)                                   |
-------------------------------------------------------

"Enable smiley replacement" option just replace text representation with an image. "Enable emoji replacement" option replaces text representation with an emoji and in addition applies the emoji font setting.

"Enable emoji font change" option would change font of anything that is shown as an emoji character, i.e.:

• With "Enable smiley replacement" option enabled it's any emoji that wasn't replaced by the smileypack.
• With "Enable emoji replacement" option enabled it's a selected through the emoticon menu, or copy-pasted from somewhere else (internet browser), or received in a message emoji, as well as an emoji that replaces some textual representation by "Enable emoji replacement" option.
• With "Enable smiley replacement" option disabled, it's just any emoji.

[Schlumpf]

I'm working on these bugs and a new smileypack handling. One question: Do we want to have a default pack inside the binary or just delivered by an installer?

[msteinbeck]

I would prefer to bundle it with an installer, because this makes things more modular.

[nurupo]

I will need to get smilies a bit of thought again, since it's a bit complicated to handle both smiley packs and emoji...

One question: Do we want to have a default pack inside the binary or just delivered by an installer?

@Schlumpf I think it's better to distribute it by an installer than packing inside the binary. We will have an installer anyway (though portable versions can be done relatively easy with some ifdefs) and there will be many resource files like sounds, smiley packs, spell check dictionaries, fonts, etc. If those things can't be found on the system, the functionality that uses them would just need to be disabled. It's not like people would try to remove all the resource files and keep just the binary, expecting it to work properly.

Any reason why it would be good to have default smiley pack, etc in the binary?

I'm planning to set up some script that would create an installer for Windows on Jenkins after I'm done with the spell check (mostly working in my local repo so far, though it's only a few commit ahead of the spellcheck branch on here). Maybe even will tackle Linux builds, if @stqism would help me by providing an appropriate build environment so that those builds could be run on Debian-derived distributions : )