Porting uses of 'accuracy' in KMimeType API

[David Faure]

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?

The mime matching tries its best to find out the mimetype based on what you 
give it (filename and/or content). The output of that is the best idea we have 
about the mimetype. What difference does it make if that's a 20% or an 80% 
accuracy?

> (Interestingly, the QMimeDataBase implementation internally plays around
> with accuracies a lot, it just isn't exposed in the public API)

Yes, as per the mimetype spec.

My guess is that it was used as a workaround for bad api or implementation, 
like "try with the content, and if that's not accurate, try with the 
filename", or vice-versa. But QMimeDatabase has the right all-in-one methods 
for this, following the spec, i.e. "if both filename and content are 
available, then trust the filename, unless there are multiple mimetypes 
claiming the same glob, then look at content, and select the one that matches 
(or is a subclass of) one of the candidates based on the filename".

The intended way to use this is to use isDefault() on the QMimeType,
if that's true then it couldn't find any specific mimetype for the file
(i.e. basically accuracy 0). And otherwise, that's the mimetype.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5