I doubt the unicode emojis have the konqi theme I'm using :-)

sure, but the world has moved on from two dozen ASCII-art emoticons that we find by string parsing to a gazillion emojis that are globally standardized in Unicode, so I think we should adjust to that reality :)

+1

Remaining users seem to be: konversation, choqok and ktp. There's also a KCM for it in Plasma, which would become obsolete as well then.

In T11585#199111, @vkrause wrote:

Remaining users seem to be: konversation, choqok and ktp. There's also a KCM for it in Plasma, which would become obsolete as well then.

VDG wanted to kill that KCM anyways.

In T11585#199105, @vkrause wrote:

sure, but the world has moved on from two dozen ASCII-art emoticons that we find by string parsing to a gazillion emojis that are globally standardized in Unicode, so I think we should adjust to that reality :)

+1 for these reasons. We are in fact now the last ones who don't have an easy emoji input panel accessible in all apps. Even Windows now has this (as do macOS, GNOME, and the others).

OK. Bye konqi :-)

Hm, there's actually one less obvious user of this: KTextToHTML in KCoreAddons access a dynamically loaded KEmoticons backend, so users of that are also affected (mainly PIM and Ruqola).
Anyway, assuming we want to get rid of KEmoticons, the next question is how. Maybe changing KTextToHtml to replace ASCII art emoticons with Unicode emojis rather than useing KEmoticons might be a way to offer a migration path?
Regarding input, kpimtextedit has a few building blocks for this, but that's unrelated to dropping KEmoticons.

Alternative idea: Keep KEmoticons, drop its image-based mappings and theming, and collect all Unicode emoji functionality there:

• ASCII-art (:-)) and colon-quoted (:smile:) translation to Unicode emojis
• functionality to support Unicode emoji browsing and input (such as kpimtextedit has, ideally without being widget-specific)

Maybe changing KTextToHtml

Makes sense.

But at runtime we also need to adjust the fontconfig quite significantly so that it falls back to loading font symbols from a font with emojis. Even with noto it's a separate family (on arch packaging at least) and doesn't work out of the box.

That's surprising. I thought Qt, when asked to render characters that aren't found in the current font, would pick up a font that has those characters.
IIRC this exists since Qt 4 or something like that.
Sounds like a Qt bug if this doesn't happen. Grab carewolf and talk to him, he touched font stuff recently in Qt :-)

I spoke to carewolf. We're both right.

There is code in Qt to handle falling back to other fonts as defined by the fontconfig config.

On my distro that config didn't work ootb. Maybe others do.
(Edit: Neon does)

In any case, I will chase up on this.

Partially related to this: is it technically possible to create Emoji fonts which show the artworks currently provided by KEmoticons themes? (including a konqui one?)

In T11585#199599, @ltoscano wrote:

Partially related to this: is it technically possible to create Emoji fonts which show the artworks currently provided by KEmoticons themes? (including a konqui one?)

Not an expert on this, but assuming you have this as vector graphics I think it's theoretically possible.

Notes from the sprint:

• add a colon-quoted and ascii art to unicode emoji conversion in kcoreaddons, based on internal static conversion tables
  • make the ascii art parsing a bit more strict, removing ambiguous stuff from the set of supported elements (ie. :-) is ok, (c) is not)
• remove the kemoticons plugin for kcoreaddons, and the kcoreaddons emoji plugin
• make use of the above in KTextToHtml in KCoreAddons
• Make Eike accept David's Konversation patch
• KTP: esoteric use due to no longer existing messaging services (thanks MS for shutting down MSN!!!)
• choqoc: portable with minor adjustments
• review existing unicode emoji based implementations in ruqola
• eventually remove the framework and its kcm in plasma