Fixing and regulating certain types of search fields across KF5 apps

[Jeremy Whiting]

Eike,

On Mon, Feb 9, 2015 at 1:03 PM, Eike Hein <hein at kde.org> wrote:

>
> Hi,
>
> we currently have numerous dynamic search fields across KDE
> apps that, for performance reasons, disregard input shorter
> than a particular QString::length(). Examples are KMail and
> some things in KRunner. It's a common pattern.
>
> This is very English-centric behavior; many scripts are
> more complex than this, in particular CJK ones. In Korean,
> a single character may be composed of multiple letters and
> form a complex syllable. Most Korean given names are two
> characters, many useful words are only one character.
> The situation in Japanese is similar - it's written using
> a mix of syllabaries and ideograms. The check for 3 has
> good intentions but breaks real use cases for these users,
> such as finding mail by name.
>
> Addressing this algorithmically is not all that hard. When
> normalizing to Unicode NFD, those complex Korean characters
> turn into a sequence of combining characters for the indi-
> vidual letters. Syllabic and ideographic code points are
> assigned the character class Lo in Unicode, which is info
> available via QChar. An NFD pass + counting Lo chars as 2
> would be simple and effective enough for this purpose.
>
> The way I'd like to see this fixed is placing an API like
> isMinimumSearchableLength(QString) somewhere in KF5 and to
> start using it everywhere. Realistically developers won't
> find this on their own, but it means I could go around and
> patch up all these places without copying code around.
>

That's a great idea imo.

>
> Which framework would be a good place for this?
>

Without giving it much thought I would think either KI18n or Sonnet.

>
>
> Cheers,
> Eike
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150209/2b93b0e4/attachment.html>