Porting uses of 'accuracy' in KMimeType API

[Milian Wolff]

On Friday 12 September 2014 21:06:36 Kevin Funk wrote:
> On Friday 12 September 2014 10:50:36 David Faure wrote:
> > On Friday 12 September 2014 09:39:42 Kevin Funk wrote:
> > > Heya,
> > > 
> > > Context: Forward-porting some patches in KDevelop involving KMimeType
> > > API.
> > > 
> > > I've just noticed that in Qt5, QMimeDataBase/QMimeType doesn't allow me
> > > to
> > > retrieve the accuracy of a match anymore, while KMimeType did. For
> > > example,
> > > compare the possible arguments for QMimeDataBase::mimeTypeForUrl vs.
> > > KMimeType::findByUrl.
> > > 
> > > What's the suggested way to deal with this? As far as I can see, there
> > > are
> > > no porting notes about that particular matter.
> > 
> > You're telling me everything I know already, but not the important bit
> > which is: what do you need the accuracy for?
> 
> Well, this is ancient, performance-critical code inside KDevelop. We
> basically cache a extension -> language mapping for performance reasons.
> Just recently we introduced code that avoids caching extensions for which
> the KMimeType lookup yielded a very low accuracy.
> 
> Also see: https://git.reviewboard.kde.org/r/120085/

With Qt5, we need to reevalute the performance of the mimetype checking. Maybe 
it's good enough nowadays. Otherwise I agree that we'll need some information 
on the accuracy of the match.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de