Smiley improvements

[nurupo]

• Remove those spaces that are added before and after a smiley.

• Restrict number of smilies.

  We want to avoid situations when a smiley pack A has more smilies than a smiley pack B, because that would result in user using B smiley pack seeing sometimes image smilies and sometimes text ones -- smiley pack B wouldn't be able to find an image for some smilies from smiley pack A.

• 1-to-1 mapping of Unicode Emoticons to image smilies, for the same reason as the previous one.

• Move the default smiley pack into a resource directory and treat it just as if it was located in a file system, instead of hardcoding the config for the smiley pack in cpp.

  That would also allow the default slimey pack to be moved out of .exe if needed without any trouble.

• Add an option to disable any smileys/emoticons.

  That should enable/disable processing of smilies and show/hide the button triggering EmoticonMenu.

• Change the way smiley settings are displayed:
  • Remove images from the combobox.
  • Show smiley/emoticon preview right in the settings dialog (remember that we restricted the total number of smilies, so this preview should fit).
  • Add a checkbox for use of Unicode Emoticons, instead of adding them in the combobox as a smiley pack.

• Make EmoticonMenu a singleton.

  Really, why it's not a singleton yet?

• When settings windows is created, it locates, parses and loads all smiley packs from a disk, which delays the settings window from appearing for quite long time. As a solution - do smiley pack loading in a separate thread.
• That settings window also caches all loaded smiley packs, which results in 24mb -> 70mb memory usage jump on my system with only single default smiley pack being cached. Mayne not cache smiley packs at all and let them load all over again when opening the settings menu? Or at least cache in some more efficient way.

[lance0]

I think about 20 smileys would do, no reason to go buckwild with them. Thoughts?

[aviau]

@blitchiz Why don't you want 1-to-1 mapping of unicode emoticons? The amount of emoticons in the unicode standard seems like a good standard to use.

[lance0]

@ReAzem can't argue with that :)

[looph]

I think I will have a go at this.

Just some minor clarification questions:

• Restrict number of smilies. We want to avoid situations when a smiley pack A has more smilies than a smiley pack B, because that would result in user using B smiley pack seeing sometimes image smilies and sometimes text ones -- smiley pack B wouldn't be able to find an image for some smilies from smiley pack A.*

Questions (bear with me if I ask things that are obvious or if I write questions about things that I've completely misunderstood):

1. Every smiley pack must implement the whole unicode set of emoticons? (76 pics).
2. If a smiley pack C implements a subset of the unicode set, the user of C will see text for the not implemented ones?. Or should we implement a standard default backup smiley pack D, that is used to find a suitable picture if smiley is not found in C?)
3. ..or shall we treat smileypacks as invalid if they havent implemented the complete unicode? (build in check/warning for that?).
4. If a smiley pack implements a superset of the unicode shall we ignore the superset or use it?*
   • 1-to-1 mapping of Unicode Emoticons to image smilies, for the same reason as the previous one.

If the user via inputtextwidget writes "haha.. :D", then:

1. find the unicode for ":D" (U+1F604),
2. replace ":D" with F0 9F 98 84(UTF8 of U+1F604) in the string if using emoji
3. ..or insert "img src="/icons/emoticons/emotion_grin.png" " if using smileypack.

The mapping should look something like this then:

1. ":D" -> U+1F604 -> F0 9F 98 84 (UTF8)
2. U+1F604 -> "img src="/icons/emoticons/emotion_grin.png" " Mapping (1.) is done internally in ProjectTox-Qt Mapping (2.) is done in the smileypack loaded by user.

If the user is using a smileypack and the Mapping(2.) doesn't exist for one unicode, then use a default internal mapping to a "img src="default... " that is included in ProjectTox-Qt.

[nurupo]

Saying upfront -- I don't use image smilies or unicode emoticons, I usually prefer using plain text ones, like US-ASCII only or Shift JIS only, so I'm not very knowledgeable about smilies.

By

Restrict number of smilies.

and

1-to-1 mapping of Unicode Emoticons to image smilies, for the same reason as the previous one.

I meant to say that we could select a set of n common smilies such that n is both in unicode emoticons and in standard smiley pack and force smilepacks to define exactly n smilies without ability to define their textual representations. In the current smiley pack you can define arbitrary number of smilies and map them to arbitrary set of strings -- textual representations of those smilies:

smile.png         :-)  :)   =)
happy.png         ^_^  ^^   ^.^ ^-^
glasses-cool.png  8-)  B-)
smile-big.png     :-D  :D   =D
grin.png          :-)) :))
tongue.png        :-P  :P   =P

and I thought of something like that:

smile=smile.png
happy=happy.png
cool=glasses-cool.png
bigsmile=smile-big.png
grin=grin.png
tongue=tongue.png

i.e. you can't specify textual representations and you have to define images for all n smilies. With such restrictions it would be possible to avoid cases when, say, smiley pack A has (beer) smiley but smile pack B has not, so to B's user it's displayed in plain text as "(beer)". There is nothing wrong with (beer) as such, but imagine if some more obscure smiley was used instead, that could even cause some misunderstanding because user A could expect user B to see the image representation of the smiley, preferably the exact same they are seeing, but user B saw a textual representation of it that could have not conveyed the the original meaning. With restrictions we can guarantee that all smiley pack have (beer) smiley, and can guarantee that it's textual representation is exactly "(beer)", not "(the_cold_and_refreshing)" or something, so that if A uses a smiley, B will definitely see it.

(The whole point of restricting smiley packs was to minimize the unambiguity that smiley packs with their missing smilies or different textual representations introduce)

Anyway, looking around a few im applications with smiley pack support I found that they generally allow smiley packs to define arbitrary number of smilies and map them to arbitrary sets of textual representation strings, so I guess smiley users are used to this and would actually expect such level of customization, so we will keep it as it is. In other words, ignore "Restrict number of smilies" and "1-to-1 mapping of Unicode Emoticons to image smilies, for the same reason as the previous one" items.

Moreover, such restricted smileypacks would fail since we are not the only client in the toxland, other clients don't have to obey those restrictions, which defeats the whole point.

[Schlumpf]

I agree. The last point is the most important: We are not the only client.

[looph]

yeah, also noticed that if the user is using unicode, then unicode will be transmitted to the receiver. It looks funny when I received it in the toxic client, because it doesn't support unicode, like :smiley: becomes ~_~X~D. When using smileypack the message sent becomes :D, which is at least understandable. It would be cool if the receiving client could detect unicode characters that it knows it doesn't support, and inform the user that it should change font (perhaps even suggest a font).

I support nurupos idea that it would be great to have some form of standardized smileys though. I guess if we create one extensive "free to use" standard library of all thinkable smileys (that could be copied to other tox-clients) then it would in fact become the standard. The other more general solution is to send smileypack pictures encoded in the actual message (yuck! ;) ).

[nurupo]

if the user is using unicode, then unicode will be transmitted to the receiver

Tox protocol specifies that messages are to be encoded in UTF-8.

:smiley: becomes ~_~X~D. When using smileypack the message sent becomes :D, which is at least understandable.

Don't understand what do you mean. Perhaps you meant ☺ instead of :smiley: ?

It looks funny when I received it in the toxic client, because it doesn't support unicode

.

It would be cool if the receiving client could detect unicode characters that it knows it doesn't support, and inform the user that it should change font (perhaps even suggest a font).

@JFreegman ^

I guess if we create one extensive "free to use" standard library of all thinkable smileys (that could be copied to other tox-clients) then it would in fact become the standard.

That still doesn't stop anyone from using their own implementation. It's also too bothersome at this point, when nightly builds are about to appear, I'm already a little angry that we deal with such side feature as smiley packs instead of implementing frontend for things that are in the toxcore or fixing some critical issues, like laggy message widget.

The other more general solution is to send smileypack pictures encoded in the actual message (yuck! ;) ).

This is insane.

[Schlumpf]

@nurupo I'm currently working on the new message display ;)

[nurupo]

@Schlumpf yeah, I saw that. It will be a long code reading for me : )

Do you know if our smileys would work there (if it support rich text image insertion)?

Also, Quassel has special way of highlighting text - you can highlight just messages, or messages and names, or time and messages and names. Would be nice if we could in Qt GUI highlight just messages, names and messages, messages and time, names and messages and time.

Also, last time I checked your fork, the lines that separate names, messages and times don't resize when the window resizes. And it didn't handle multiline messages (ones with s in them) correctly.

[Schlumpf]

I'm currently (in this moment) working on the selection ^^ Smilies won't be easy to implement, because of Quassel paints the text on their own, very low level code. I think, I have to paint the smilies in this low level way, too. But I don't spend much time on thinking about that yet.

[nurupo]

Yeah, we can just put smilies on hold and come back to them later. I just will finish cleaning up smileypack.cpp, emoticonmenu.cpp and settings so that they will be ready to go if needed.

[looph]

Ok, so this smileypack issue #83 is not relevant at the moment, or at least until the new message display is implemented?.

One last quick question:

• Move the default smiley pack into a resource directory and treat it just as if it was located in a file system, instead of hardcoding the config for the smiley pack in cpp.

If I understood it correctly, fixing the above would mean:

• remove the defaultList in smilieypack.cpp/guisettingspage.cpp
• create a theme file in the repo resources/icons/emoticons/, set Name to "TOX Qt GUI Smileys".
• Instruct the developers in the install.md to copy /emoticons/ directory to .config/smiley/ (this part will later be automatically done by the installer).

[nurupo]

Yeah, something like this, except renaming the emoticons directory into smileys, to be consistent with .config/smileys/ directory. Also, emoticons should probably be moved out of icons into resources then.

Instruct the developers in the install.md to copy /emoticons/ directory to .config/smiley/

The .config path might differ depending on OS. There is a Qt call that gives a path to a suitable for saving application's settings on current OS directory, so the install.md part would be kind of tricky to write

[nurupo]

• Remove those spaces that are added before and after a smiley.

@Schlumpf why do we need those non-breaking spaces here?

[Schlumpf]

@nurupo There is a problem with the input of emoji in different sizes than the normal text. If the user inserts a emoji from the emoticonmenu with no space at the end, the next characters will have the other size, too. I don't like the space, because of if the user sets the cursor between emoji and the space, he is able to write in the emoji size.

I would prefer to disable the smiley/emoticon preview in the input widget.

[Schlumpf]

notice: https://www.dosomething.org/petition/emojis

[nurupo]

Can you elaborate more on how is that related to Qt GUI?

[Schlumpf]

There is no direct connection. Just a note, that emoji will expanded, maybe.

[nurupo]

@Schlumpf I got somewhat interested in QChar::ObjectReplacementCharacter (U+FFFC) after the https://github.com/nurupo/ProjectTox-Qt-GUI/issues/118 and I found that you can actually insert custom objects into QTextEdit by using that QChar. Qt doc entry, Qt example (some googling: 1, 2, 3, 4).

Though the doc says:

Warning: Copy and Paste operations ignore custom text objects.

(perhaps irrelevant, but that is pretty cool too)

[Schlumpf]

I'm using that for #116 ;)