On Thursday 15 September 2011 09:50:02 ext David Faure wrote: > Also, it exposes too much internals of the spec, such as the various fields > for magic (content-based) matching; this is all because QtCreator has a GUI > for defining your own mimetypes, but I can't think of any use case for a > user defining his own magic rules...
According to the code, the list of attributes in qmime is as follows: > QString type; I called that name. The spec calls it type. I should probably change, then. > QString comment; I call that displayName. The spec calls it comment. I should probably change, then. > LocaleHash localeComments; I have no name for that because I didn't know where the actual translation would happen. If the consensus is that the translation should be in here then I will add that, too. > QStringList aliases; I don't have that in my API. What is the use case for that? > QString genericIconName; I call that iconURL. Since I am not convinced the generic-icons will be installed on every platform Qt runs on I favor to return a complete path to the icon. I should probably change the type from QString to QUrl, right? > QList<QMimeGlobPattern> globPatterns; I don't have that in my API. What is the use case for that? > QStringList subClassOf; I don't have that in my API. I could add that. > QString preferredSuffix; I don't have that in my API. I could add that. > QStringList suffixes; With my latest patch that is waiting for the mirror to kick in, I call that filenameExtension. I can't find it in the spec, though. What does everybody prefer? > QList<QMimeMagicRuleMatcher> magicMatchers; I don't have that in my API. What is the use case for that? _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
