> Well, this has to look at inheritance too, it's not a simple algorithm. See > the comment above KMimeType::findByUrlHelper for more details. > > Also there needs to be a "findByNameAndData" where the data doesn't come from > a > file but from a memory buffer. And the qtcreator code doesn't look into the > right places for mimetypes, it doesn't follow the xdg base dir spec (but more > generally this should be provided by e.g. QDesktopServices anyway). > > And you're not handling glob-deleteall (__NOGLOBS__ in the globs2 file), > which > is necessary for handling user-defined changes (removing a glob from a > mimetype).
Yes, i already saw that comments. Qt Creator's code have function that uses just QByteArray (not QIODevice, like KDE), so there's no problem to uses raw data from buffer. Support of this places should be done, agree. > 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 are also tests about user-defined mimetypes in kde- > runtime/keditfiletype/tests/filetypestest.cpp but these might be harder to > port. This tests should stay the part of KDE in case they can (not all of them) be useless on other platforms. > OK, this could use caching, that's an easy fix. Yep. > 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). > shared-mime-info already generates 'databases' (simple text files) for faster > glob parsing and magic matching, without the need to parse the xml files. See > the "globs2" and "magic" files. We only need the xml files for icon and > comments, but that's not the most common use case. > We should optimize the API for the most common use case, which is "give me > the > mimetype name for this file and/or data". Looking up the details of that > mimetype (icon, comment, etc.) should only be an optional second step, since > this requires parsing XML files, while mimetype-matching does not. I did this > inside KMimeType by parsing the details 'on demand', but we could also do > this > by returning a QString from the "findBy" methods rather than a QMimeType. > > I don't think we need a cache in binary format, when there are already caches > available, pre-generated at install time (so no performance penalty at all > for > generating them while the application is running). Well, using text files not good idea - in fact, parsing whole freedesktop.org.xml file takes little time. 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. > I would rather say, you need to rewrite the algorithms to use "globs2" and > "magic", and I have the exactly code for that. > > 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?
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
