26.09.2011, в 12:46, Wolf-Michael Bolle написал(а): > 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. I never said we have not to support user mime types, you just removed them without any asking. > Working code does not make the code a good candidate for a public API in Qt. > Since I've started with Nokia I've learned that the standards for Qt are > *very* high. The solution to separate working code that should be in the > public API of Qt from code that should stay out of it but keep on working is > to refactor that code out into either an internal API of Qt or even into the > realm of the actual application. > > Let's go though your individual changes: > > In BaseMimeTypeParser, you suggest to reintroduce the static methods > readUserModifiedMimeTypes() and writeUserModifiedMimeTypes(). I don't like > it. But since it's internal I can probably live with it. As i said, we can remove writing at all - it uses only public API and can be implemented by user. > 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. > 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. > In QMimeType you suggest to remove the clear() method. I am fine with that. I > don't need it. Ok. > 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. > 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. I don't understand why you afraid of user mime types. Most you arguments can be used to remove dynamic properties from QObject:) _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
