Fixing and regulating certain types of search fields across KF5 apps

[David Faure]

On Tuesday 10 February 2015 14:48:51 Eike Hein wrote:
> 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.

Yes.
 
> 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.

That's just a naming issue. KCodecs was shorter than
KInternationalTextHandling

> * 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.

I think you mean the KCharsets class in the KCodecs framework.
The rest will probably survive it.

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

I disagree. I'd like ki18n to remain "a translation framework, alternative to 
tr()". If we start packing more stuff into it, then we can't switch between 
i18n and tr for a given framework, because there will be this extra stuff in 
ki18n.

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

KCoreAddons was my first thought but I don't like the general direction of it 
becoming a catch-all framework. KCodecs fits better, with the general idea of 
"international text handling" rather than just encodings.

And KGuiAddons would only be right if your code needed QtGui. But yeah that's 
something to find out for sure - if a future implementation might need QtGui, 
then the API should be in KGuiAddons from day one. This consideration makes it 
hard to just say "we can always rewrite the full implementation later"....

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5