kfilemetainfo using strigi
faure at kde.org
Fri Jan 12 11:51:55 GMT 2007
On Friday 12 January 2007 11:20, Jos van den Oever wrote:
> 2007/1/12, Sebastian Trüg <trueg at k3b.org>:
> > How about providing a compatibility wrapper strigi plugin that is able to load
> > KFilePlugins? This way all the old plugins could be reused until they have
> > been ported. Is that possible or do we get a problem with the streaming
> > issue?
> This is a possibility, yes. This will only mean that files that are
> not readable through QFile will not work. This is the case now too, so
> there's no problem there.
> The hard bit is in how to change the API of KFileMetaInfo. Some things
> in there have to change:
> - Interface must pass a QIODevice and not a QFile (easy change)
> - We have to reconsider the role of the mimetype. In Strigi mimetype
> has no meaning. Each analyzer looks at the content of the file and
> determines from that what it can get out. In KFileMetaInfo, the
> combination mimetype + KFilePlugin instance determines the fields that
> could be available for a file. In Strigi you dont need the mimetype
> for that, but you do need to know if an analyzer can handle a specific
You just need an intermediate layer then.
KFileMetaInfoStrigiAdapter (or any shorter name) would be the strigi analyzer that
implements that strigi interface ("can you handle this file?") and the implementation
of that would
1) determine the mimetype (KMimeType::findByPath)
2) find and load the KFilePlugin for it
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel