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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
