Hi David,
> I thought a bit more about where to get the mimetype definitions from, and
> I can see three "backends":
> 1) the current "parse the big XML file" backend,
> 2) the current KDE solution of parsing the generated text files (globs2,
> magic, aliases, etc.),
> 3) and the recommended-but-not-implemented-yet solution of parsing the
> generated mime.cache files (in addition to per-mimetype xml files when one
> asks for a mimetype's translated comment).
>
> Solution 1 is slow, but has the advantage that it can be more easily
> deployed, to Windows, without a dependency on shared-mime-info's
> "update-mime-database" program.
>
> As with any computing problem, it could be solved by another layer of
> indirection :-)
>
> class QMimeProviderBase
> {
> public:
> QMimeProviderBase();
>
> virtual void parseGlobs() = 0;
> [and similar methods, parseMagic(), parseSubclasses(), parseAliases()]
> // and virtual QString commentForMime(const QString &type) = 0;
> };
>
> class QMimeSystemProvider : public QMimeProviderBase
> {
> public:
> QMimeSystemProvider();
> // Parse the generated files (globs2, magic, subclasses) on demand
>
> virtual void parseGlobs();
> };
>
> class QMimeXMLProvider : public QMimeProviderBase
> {
> public:
> QMimeXMLProvider();
> // Do XML parsing and store the results
>
> virtual void parseGlobs();
> };
>
> class QMimeBinaryProvider : public QMimeProviderBase
> {
> QMimeXMLProvider();
> // Parse mime.cache (possibly on demand, for its different areas?)
>
> virtual void parseGlobs();
> };
>
> // In QMimeDatabase, we would do
> // if system mime.cache found, new QMimeBinaryProvider
> // else if system globs file found, new QMimeSystemProvider
> // else {
> // look for freedesktop.org.xml file in the system
> // if not found, use Qt's own copy
> // new QMimeXMLProvider
> // }
>
>
> How does this sound?
> Useful or over-engineered?
> Missing any use case?
>
> This will remove the need for QMimeDatabaseBuilder (I'll just pass the
> QMimeDatabasePrivate pointer to the provider), and hide the details of
> "where the mimetype definitions come from", from the applications.
I like your ideas - even though for very different reasons than you. ;-)
I've just finished synching QtCreator with qmime, and as it turns out QtCreator
has some very special requirements for MIME type handling which your
backends could help me solve. I have come to understand that QtCreator is
maintaining a local MIME database that is completely independent from the
system MIME database, and is built from scratch from XML files that are part of
the QtCreator distribution. Your proposal would allow me to have seperate
backends for the system MIME database and QtCreator's local database.
As you can see in my branch I have blown up the interface of
QMimeDatabaseBuilder quite extensivly for QtCreator. If QtCreator got full
access to its backend then almost all of the methods could more or less go
away. We shouldn't kill the class right away though ...
What are your thoughts about binary compatibility? We need to make sure we
don't shoot ourselves in the legs because of vtable changes.
Michael
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
