// Forwarding private letters so others can take part in discussion. Начало переадресованного сообщения:
От: David Faure <[email protected]> Дата: 5 июня 2011 г. 16:32:29 Московское летнее время Кому: Иван Комиссаров <[email protected]> Тема: Ответ: QMimeType On Sunday 05 June 2011, you wrote: > Hi. > > I don't think it is good idea to start refactoring code again. In fact, it > seems i only have problem with mimetypes with same extension, however i > know the way to fix it and it won't take lot of time. 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). > I also have lot of > tests and i'm working for 100% coverage of them. Not sure, but i hope data > search is correct now. I strongly suggest to import the tests from kdelibs/kdecore/tests/kmimetypetest.cpp There are also tests about user-defined mimetypes in kde- runtime/keditfiletype/tests/filetypestest.cpp but these might be harder to port. > Also, some parts of KDE mime should be entirely rewritten - for example i > don't think it is good idea to recreate mime type from file each time we > call KMimeTypeRepository::findMimeTypeByName function. OK, this could use caching, that's an easy fix. > Besides, you need do same refactoring as i already done - removing most > shared pointers to classes, reducing number of interfaces, making code > more readable (this part is not so important for you as was for me:) ) Yes, the best outcome would probably be your API with my algorithms... > About functionality - i plan to store mimedatabase bot in binary format > (for faster loading) and xml (to allow user create own mimetypes/overwrite > standard one from database). KDE's classes work only with xml with > separate files and it should be rewritten. 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). > So, i think there is same amout of work with both classes (you need to > rewrite some algorithms, i need to cover all tests). I would rather say, you need to rewrite the algorithms to use "globs2" and "magic", and I have the exactly code for that. > I will be very pleased if you help me with test coverage 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. > every test makes shows how little i know about mimetypes:) Hmm :-} -- David Faure, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
