On Thursday 15 September 2011 14:22:26 Иван Комиссаров wrote: > As far as i remember, i asked David to use kde code to read mime types… > Dunno why it is still not in repo:)
Well the very first step was to get QStandardPaths into Qt, so that we can locate the files generated by shared-mime-info on disk. It took a long time (due to 3 platforms, due to review process, and due to the refactor branch being merged into master), but it's finally ready. Not merged yet, though. Also, my first commits to qmime.git were moved to a branch and never merged in, I don't take that as a sign of fruitful collaboration... > About editing mimetypes - as far as QtCreator use editing it is good not to > duplicate 2 databases - one 1 in Qt (read-only), other in Qt creator (with > ability to add custom mime types). IMHO the editing of mimetypes in Qt Creator should be removed. I asked danimo and he was very surprised to hear that such a thing existed. But if Qt creator should really allow editing of mimetypes, then it should edit the system mimetypes (I have code for that too...). The concept of per- application mimetypes breaks the concept of shared-mime-info. > > " it exposes too much internals of the spec, such as the various > > fields for magic (content-based) matching" > It is just 2 (two) methods in QMimeType… "too much", yes… Besides, they can > be moved to QMutableMimeType (class for constructing new mime types) and > most users won't see this details. Moving to another public class doesn't change the issue: if it's in the API, it can't be changed later. Same thing with the glob weights -- this shouldn't appear in the API, because that makes it impossible to change if the spec changes. In fact this wasn't in the spec initially... these things -can- change. > In windows and mac native databases differ from shared mime info database - > in win you can't search for mime type by content, only by extension; as for > mac, names for mime type differs from shared mime info spec - for example > "mkv" is something like "movie", not "video/x-matroska". As you support > shared mime info names in QMimeData, you have to map mac mime names into > shared mime info names. > > I don't see any reasons to throw out mostly working code, except for > searching algorithm, which can be replaced by kde one (10 minutes of work) > and reading database, which is not exist in both implementations. Well, apart from the "too many details about the spec" the API in qmime.git is mostly good, I like QMimeDatabase. But the code is mostly about parsing XML files... Well, anyway. I'll let you and Wolf-Michael debate about which API is chosen for inclusion into Qt, and only then I'll implement the shared-mime-info backend into the chosen repository. Better not do it twice. > So, we also have open question about storing mime types under mac/win - user > won't copy million text/xml files to deploy his program. There is just one xml file to copy. The rest is generated by update-mime- database. But I can see that given Windows's non-existing dependency handling, this might not be a great solution ;) An alternative could be that Qt ships the files generated from freedesktop.org.xml, and [on any platform] if shared-mime-info is installed we don't use those. Note however that without shared-mime-info's update-mime-database program there is no chance of defining new mimetypes (which is fine IMHO, it's not needed by typical Qt apps). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
