[Qt5-feedback] QMimeType
David Faure
faure at kde.org
Thu Jun 9 00:23:19 CEST 2011
On Sunday 05 June 2011, Иван Комиссаров wrote:
> > I strongly suggest to import the tests from
> > kdelibs/kdecore/tests/kmimetypetest.cpp
>
> Ok, i'll take a look at those tests. I used test that provided with
> shared-mime info and i think we don't need to support more
There is a huge flaw in this reasoning.
The shared-mime-info tests ensure that freedesktop.org.xml is somewhat
correct. They do not however test all the cases of the required algorithms
(glob conflicts etc.). I wrote these tests for a good reason...
> > Yes, the best outcome would probably be your API with my algorithms...
>
> In fact, both my API and algorithms should be changed in some way. I really
> hate having shared pointers to MagicMatchers and maybe the right way to
> remove them at all and leave only magic rules for user. About algorithms -
> Creator algorithm (even with lot of my changes) does not provide full
> support, so it should be changed or can be replaced with your code. The
> problem is that you always try to find best match, however it seems not
> always accords specification (i have test which say that JPEG file named
> image.tiff should FAIL (i.e. return not jpg) when trying to search by name
> and data - really strange, but seems it accords spec).
Yes, the extension prevails. So that users can actually be in control.
Magic matching is too unreliable to rely too much on it, it's only a useful
fallback when the extension is completely unknown or absent.
I am pretty sure that KMimeType follows the spec on this.
> Well, using text files not good idea - in fact, parsing whole
> freedesktop.org.xml file takes little time.
Parsing XML is much slower than parsing text files.
Of course in the case of one big app like QtCreator it doesn't matter much,
but when in Qt this will be used by many many smaller apps, and there it does
matter.
> The only thing we can do -
> optimize whole base or not optimize at all. I think we need to discuss
> this more - when writing standalone Qt app user want to minimize files it
> should place near app (in kde you have this files already present in
> system, which is not true for mac/win). So having 1 binary base is much
> easier then xml+globs+magics.
You expect people to deploy binary caches instead of actual extensible files???
This makes little sense to me -- especially since apps must be able to add
their own mimetypes. Creating a new (binary) format instead of the standard
format is really not going into the right direction.
Anyway -- Windows is a whole other issue. The "right" thing to do for
QMimeType would probably be to work with the Windows mimetypes rather than
with the shared-mime-info mimetypes... This, however, isn't really something
I'm interested in working on.
Not sure if Mac has a mimetype registry.
> > I would be happy to help with tests, but only if I can also change the
> > algorithms to use the ones that have proven stable for many years and
> > many people. Otherwise I'll have to do my own proposal for mimetypes in
> > Qt, and I don't think any of us wants to see duplication of efforts.
>
> Of course, my algorithm SHOULD be rewritten to cover all tests. However,
> before rewriting we need to decide which features we support and which
> don't. If you want to participate you can use every code which is already
> present in kde/qmime. But first i need to take closer look at kde code to
> understand how conflicts are resolved (for example both
> "application/x-sami" and "appication/smil" have same extension ".smi"). I
> guess you use order in which globs are placed in globs file?
No. Please read the spec, there are glob weights, and in case of equality,
magic is used to determine the winner. See also the long comment in
kmimetype.cpp which I pointed you to, it explains how "determining the winner"
actually works: there's a special case to handle when the magic points to a
base class of the candidates rather than pointing to an actual candidate
itself (the result should be the candidate-from-glob-matching rather than the
base-class-from-magic-matching).
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the Qt5-feedback
mailing list