Smileypack support

[Schlumpf]

There are different clients in the TOX network. So they will have different emoticons. We need to have an option to use different (user created, too) smileypacks in the Qt GUI.

I would like to implement that, here are some thoughts about it.

• smileypacks consist of a folder including the images (*.png) and a control file (theme)
• The theme file looks like this:

Name        = Packname
Description = Short package description
Icon        = smile.png
Author      = Creative guy
Email       = c.guy@free.net
Website     = http://homepage.com
License     = CC
Version     = 1.0

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

• All smiley pack folders are located in [QStandardPaths::ConfigLocation]/[AppInfo::name]/smileys/
• The config dialog (GUI page) gets an option to select the pack
• Compatible to pidgin smiley packs
• I can't use ini-files because of limitations with special characters in Qt's ini-parser
• emoji support

Tell me what you think. What should be changed?

[JamoBox]

Sounds like a very nice idea, too many applications have smiley sets that look terrible cannot be changed, and it sometimes ruins a good piece of software. I believe having this kind of control over the application will entice a lot of users.

[nurupo]

I have mentioned support of smiley packs on IRC (and here), saying that this was somewhere on the todo list, so yes,

We need to have an option to use different (user created, too) smileypacks in the Qt GUI.

Your organization of smiley packs and the theme file look good. I think we could add delimiter key, which would define a delimiter between different textual representations of smileys, just in case some of them include the space character as part of the textual representation (are there even such smileys?) . To provide a little more information license, email, website, version and date can be added.

Also, someone on IRC asked to add support of emoji, so we might give it some thought. They became popular on iPhone, they were added into Unicode Standard 6.0, Microsoft added out of the box support of emoji in Windows 8.1 and even made a patch that adds that feature to Windows 7, OS X already supports them and there are some packages one can download for Linux. It looks like that they would become pretty common in the future. They are just plain text, so you can easily copy-paste them around (no desmile() or smile() required), you can make them infinitely large, since they are vector images, etc. As I understood, in order to use them we just need a freely licensed font that has those unicode characters drawn, because users might not have such font; emoji came into Unicode Standard in late 2010, when most fonts people use are much older than that and/or don't care about displaying smileys. Qt5 supports Unicode 6.2 and can load a font from file during runtime, so there shouldn't be a problem. Here is a subset of emoji that would be of most interest to us, Emoticons.

[Schlumpf]

Yes, emoji sounds nice :)

I thought about that delimiter thing. A delimiter would make the file less readable and you can't use a delimiter character/string, what could be part of a smiley. So I decided to use whitespace as delimiter. I couldn't find any smiley, which includes spaces.

[nurupo]

Anyway, having a delimiter with a default value of ' ' wouldn't hurt. QSettings will just use the default value if there is no such key, and if someone would really need to have a delimiter different from the space in their smiley pack, it would be possible to do. Also, since the file would be read-only, the delimiter key won't suddenly appear in the file.

The better way would be to use QSetting's arrays, since that would eliminate the need in any delimiters, but QSetting's array format is poorly readable (just look at the default settings file), which would in tern require some kind of smiley pack editor either embedded in the client, or as a separate executable, which we want to avoid with readable files.

Now that I think about bad array syntax, Qt 5 supports json, which has better syntax for arrays than ini. Yaml would serve better for this purpose, it's made to be human-readable, but Qt doesn't support it, so that would require third-pray library. The only visual drawback is that Json uses ,, "", {} and [] everywhere (when yaml doesn't). Also, want to note that one would have to escape characters in both ini and json files (not sure about yaml), which doesn't increase readability much. Here is how it would look like in json:

{
  "Name":        "Packname",
  "Description": "Short package description",
  "Icon":        "smile.png",
  "Author":      "Creative guy",
  "Email":       "c.guy@free.net",
  "Website":     "http://homepage.com",
  "License":     "CC",
  "Version":     1.0,

  "smileys": {
    "smile.png":        [":-)",  ":)", "=)"        ],
    "happy.png":        ["^_^",  "^^", "^.^", "^-^"],
    "glasses-cool.png": ["8-)",  "B-)"             ],
    "smile-big.png":    [":-D",  ":D", "=D"        ],
    "grin.png":         [":-))", ":))"             ],
    "tongue.png":       [":-P",  ":P", "=P"        ]
  }
}

or, with different formatting:

{
  "Name":        "Packname",
  "Description": "Short package description",
  "Icon":        "smile.png",
  "Author":      "Creative guy",
  "Email":       "c.guy@free.net",
  "Website":     "http://homepage.com",
  "License":     "CC",
  "Version":     1.0,

  "smileys": {
    "smile.png": [
      ":-)",
      ":)",
      "=)"
    ],
    "happy.png": [
      "^_^",
      "^^",
      "^.^",
      "^-^"
    ],
    "glasses-cool.png": [
      "8-)",
      "B-)"
    ],
    "smile-big.png": [
      ":-D",
      ":D",
      "=D"
    ],
    "grin.png": [
      ":-))",
      ":))"
    ],
    "tongue.png": [
      ":-P",
      ":P",
      "=P"
    ]
  }
}

[Schlumpf]

Ini: An optional delimiter is ok. I agree. Using QSettings for parsing this files doesn't work well. Qt doesn't read values including , (komma space) except the value is wrapped in "". So, I thought about parsing the document on our own, without QSettings. In that case we wouldn't have problems with special characters.

Json: I like this idea, but we would loose compatibilty to smiley packs of other apps like pidgin. The question is, do we need this compatibility at all? Another point is the readability, it should be as easy as possible for pack creators.

Yaml: A third party library for only reading smiley pack files? I think that's too much.

Maybe we should really parse the file on our own... I don't want escape characters.

[nurupo]

Okay, so I see two solutions to this, which extend to separate projects if we want other clients to support this:

1. Make our own file format and parse it
   • Pros:
     • Easy to implement, given we keep the file syntax simple.
     • Easily editable in any text editor.
   • Cons:
     • If other clients would want to add support of our smiley packs, they would need to write their own parser. (We could make smiley pack format universal among clients by making a separate repo for parser library in C, so that other clients could use it, then this con would disappear)
     • Smiley pack creator wouldn't know what he/she did wrong (wrong smiley size, wrong file format, wrong phase of moon) unless client would throw smiley pack errors at users or have some kind of Validate option.
     • More error prone than other well-tested formats/libraries
     • Would be read-only
2. Use json, but provide a GUI interface for making smiley packs
   • Pros:
     • Well-known format, other clients would just need to use json library
     • GUI interface is nicer than plain text file
     • Allows to do checks when creating smiley pack, like if the smiley size is within acceptable range, file format is the right one, etc.
   • Cons:
     • Would require to write a GUI interface for creating smiley packs, since we want to avoid dealing with escape characters (We can actually make a separate repo for the smiley editor, in Qt+C++ or Java Swing, so that it would run on most platforms and clients wouldn't need to embed it if they want to provide way to create/edit smiley-packs)

I like the second option better, with making a separate editor. Other clients would benefit from this and presumably even contribute and support it. Although that would be harder to implement than the first one.

Anyway, we will have to ask guys on #tox-dev about this before deciding anything for ourselves, if we don't want all clients have different smiley pack formats : )

[Schlumpf]

We decided to write our own parser for the "ini like" pidgin file format (see above).

[nurupo]

Closing the issue since smiley support was implemented. Adjusting it to the future message display widget would be a whole different issue.