Fixing and regulating certain types of search fields across KF5 apps

[Eike Hein]

On 02/10/2015 01:30 PM, Sebastian Kügler wrote:
>> Without giving it much thought I would think either KI18n or Sonnet.
>
> Or perhaps kcodecs, sounds like an encoding-related problem to me.

KCodecs was my first thought too, because:

* I'd really like it to be a Tier 1 framework dep-wise and
   KCodecs makes the list.

* KCodecs has APIs to, in practice, deal with international
   text data. It also has KEMailAddress ...

* All of the code in KCodecs deals with text data under the
   hood-style.

The counter-arguments are that:

* Technically, writing system != encoding. These problems
   arise independently of how the text is encoded, although
   encoding figures into the implementation of the solution
   because Unicode helps.

* I worry a little how much of a future KCodecs has. I've
   committed fixes to it recently, and while it still does
   things Qt doesn't, it's also one of those unhappy areas
   where we wrap increasingly-powerful Qt API very tightly
   and have annoying problems with keeping it in sync.

ki8n might be more appropriate since it's about
internationalization handling on a higher level.

We also have stuff like KTextToHTMLEmoticonsInterface
that does stuff with text in KCoreAddons, though, and
KWordWrap in KGuiAddons ...

Tricky :)


> Cheers,

Cheers,
Eike