Fixing and regulating certain types of search fields across KF5 apps

Eike Hein hein at kde.org
Sat Feb 14 16:20:16 UTC 2015



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 "we can always rewrite the full implementation later"....

At the moment I can't really see a QtGui dependency ... the
only way GUI could factor into it is if we ever want to take
glyph rasterization into account (i.e. make use of font
metrics as a factor), and that seems all kinds of wrong to
me semantically, or rather, I don't think you could derive
a more useful guess about information complexity from
rasterized size than from abstract token data. Plus this
would constrain the usefulness to GUI apps, while I can see
something like this also be useful in daemon or CLI util code,
so making sure it stays GUI-free might even be a desirable
constraint anyway.

I'll be submitting something for review for KCodecs then.


Cheers,
Eike


More information about the Kde-frameworks-devel mailing list