Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-14 Thread 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: *

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-14 Thread Eike Hein
On 02/14/2015 11:49 AM, David Faure wrote: 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

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-10 Thread Aleix Pol
On Mon, Feb 9, 2015 at 9:03 PM, Eike Hein h...@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

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-10 Thread 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

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-10 Thread Eike Hein
On 02/10/2015 01:01 PM, Aleix Pol wrote: I like the idea. Have you checked whether ICU provides something like this? They might... To approach this more broadly: The basic problem here is that not every character code point in Unicode stands for a single phoneme; in the examples I mentioned

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-10 Thread Sebastian Kügler
On Monday, February 09, 2015 13:12:24 Jeremy Whiting wrote: 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

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-10 Thread Sebastian Kügler
On Monday, February 09, 2015 13:12:24 Jeremy Whiting wrote: 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

Re: Fixing and regulating certain types of search fields across KF5 apps

2015-02-09 Thread Jeremy Whiting
Eike, On Mon, Feb 9, 2015 at 1:03 PM, Eike Hein h...@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

Fixing and regulating certain types of search fields across KF5 apps

2015-02-09 Thread Eike Hein
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