Hi Иван, > > The consensus on the list seemed to be that we want > > - to have a clean and minimalistic public API > > - to not support editing / user MIME type use cases > > This is your consensus, not mine.
My understanding is that user-defined MIME types are for supporting editing MIME types. Please correct me if I'm wrong there. Maybe in a moment of overexcitement I streched the meaning of consensus. I didn't means to hurt your feelings. Still, I believe the subject has been discussed on the list extensively and resulted in the majority and seniority of the people speaking out against non- common features in the public API for MIME type support in Qt like editing: Lars Knoll: "And the question is whether this is a use case that should be supported by Qt essentials. I don't think so." Lars Knoll: "MIME type handling should become part of the basic offering. But only for the common use case of reading them and figuring out the MIME type of files and data." Thiago Macieira: "I'm of the same opinion. Writing Qt functionality that benefits one application in the system seems superfluous. We're trying to resolve the common case here. If editing MIME types turns out to be a common task, then we can revisit." David Faure: "IMHO the editing of MIME types 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 MIME types, then it should edit the system MIME types (I have code for that too...). The concept of per- application MIME types breaks the concept of shared-mime-info." David Faure: "Yes, and this (Sometimes - quite rare though, an application really need it's own format of files for its inner purposes. That's why creating of custom MIME types can be useful sometimes.) can be done by installing an XML file, no API needed." David Faure: "Same thing with the glob weights -- this shouldn't appear in the API" David Faure: "Applications can define new MIME types by installing an XML file into a location that will be seen by update-mime-database. This does not require API with all the little details of the spec, it simply requires one XML file." David Faure: "As Wolf-Michael noted, the API for creating MIME types doesn't really belong in there; that's far too system-dependent, and far too "rare" compared to queries." My personal experience and their explanations also lead me to believe that this is the right way to go. > I never said we have not to support user mime types, you just removed them without any asking. I removed them in my branch as you instructed. Nobody on the list objected to my changes and I understood your merging of the code into master as acceptance. > > In QMimeDatabase, you suggest to reintroduce userMimeTypes(), > > addUserMimeType(), removeUserMimeType(), userMimeTypeFile(), > > setUserMimeTypeFile(), readUserMimeTypes() and writeUserMimeTypes(). I > > definitely object to those. The public API should not support user MIME > > types. If you want QtCreator to support that I suggest you move that > > somewhere internal. I'd even go as far as to move it back to qtcreator > > where that code came from. > > So QtCreator will use private headers, great. File managers should use > private headers. They will break any time Qt changes. Can you explain what you mean? I don't understand what you are trying to say. About the usage of private headers I'd like to add the following: If the internal API of Qt changes in a new release, a new release of Qt Creator as the user of of that API would be necessary. Since both are currently released by Nokia (and in the future by some Open Governance body) I see no problem here. > > In QMimeDatabasePrivate you suggest to reintroduce userMimeTypes and > > userMimeTypeFile. I suggest to move those together with code above back > > into qtcreator. > > We can't. Creator should use private headers. Sorry for my asking but why not? > > In QMimeType you suggest to reintroduce the getter magicMatchers(). I > > definitely object to that because it reintroduces the class > > QMimeMagicRuleMatcher into the public API. I removed that dependency on > > purpose. Please make qtcreator use QMimeTypeData to access that data. > > > > You suggest to introduce a QMimeTypeBuilder class to the public API. I > > definitely object to that. Reason #1: All of that is accessible via > > QMimeTypeData, reason #2: Such a class currently should be part of the > > internal API at best, reason #3 Lars Knoll told me personally to not do > > it. > > User can't user private data. Of course the user can. It's part of the internal API. It's not nice but any Qt code is allowed to use internal APIs. > > I hope I didn't scare you off too bad. My offer to help you with > > qtcreator is still valid. Do you have a specific branch of qtcreator > > that you work with? I'd really like to support you with that. > > No. The changes i maid to code are very big. I don't want to replace > QtCreator's mime types right now. Are the changes you made to the code related to MIME types or something completely unrelated? If your branch contains more than just MIME type work than I suggest we create a branch just for MIME type work that the two of us can work on. What do you think? > I don't understand why you afraid of user mime types. Most you arguments > can be used to remove dynamic properties from QObject:) IMHO user MIME types do not belong into a public minimalistic Qt API. The purpose of that API is to support the most pressing and average use cases. User MIME types belong to a very specialized and if you ask me very rare use case that the application should handle by itself. Michael _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
