Review Request: Adding support to KMimeType for guessing the mimetype by content fetched from an abstract QIODevice

Friedrich W. H. Kossebau kossebau at kde.org
Wed Sep 23 17:33:18 BST 2009


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1696/
-----------------------------------------------------------

Review request for kdelibs.


Summary
-------

KMimeType already supports the detection of the mimetype from data in the working memory. But only using QByteArray as a container class.

Now in Okteta, the hex editor from kdeutils, the data is not stored in some continuous memory range, so wrapping it in QByteAray::fromRaw() does not work. And creating a data copy just for mimetype detection does not look like the smartest solution. Especially, as "KMimeType::findByContent( const QByteArray& data )" is just a wrapper to opening a QBuffer buffer on the data object and calling "KMimeTypeFactory::findFromContent( QIODevice* device, ...)", passing the buffer as device.
It would be great it KMimeType could do the type guessing for the opened documents in Okteta also based on the content, especially as the data is already locally available (same addressspace, fast working memory), and writing a dedicated (readonly) QIODevice subclass for access is an acceptable overhead IMHO.
Others might have similar needs, e.g. with files/data streams stored encoded in some containers and okay to be decoded on-demand by a QIODevice (only a small part of the data might be used, so decoding all of it by default is waste of resources). E.g. Ark might have use for it to detect the mimetype of the files in archives (currently done only based on the filename).

Attached patch adds two methods, which overload the two mimetype detection methods using a QByteArray argument as content with QIODevice argument as content provider. For KDE 5 the QByteArray ones might even be removed, being the simple, but limited to continuous data wrappers they are.

Okay to commit?


Diffs
-----

  trunk/KDE/kdelibs/kdecore/services/kmimetype.h 1025071 
  trunk/KDE/kdelibs/kdecore/services/kmimetype.cpp 1025071 

Diff: http://reviewboard.kde.org/r/1696/diff


Testing
-------


Thanks,

Friedrich W. H.





More information about the kde-core-devel mailing list