From kossebau at kde.org  Wed Sep 23 19:03:30 2009
From: kossebau at kde.org (Friedrich W. H. Kossebau)
Date: Wed, 23 Sep 2009 19:03:30 +0200
Subject: Useful for Ark? KMimeType::findByContent( _QIODevice* device_,
	int* accuracy ) etc.
Message-ID: <200909231903.31974.kossebau@kde.org>

Hi Ark developers,

if I looked correctly at the sources of Ark (are good to read, thanks) your 
are only using KMimeType::findByPath() with the given filename to get the 
type of a file in an archive, right?
(And by accident I had just yesterday some files without extension in an 
archive which thus had no mimetype shown in the list).

I guess you do that on purpose as you do not want to extract whole files just 
for mimetype detection. And the current interface of KMimeType either asks 
for a file or a QByteArray to also use the content for type guessing.

Now, in Okteta I have a similar problem: The (edited) data of some file is not 
available in a continuous range in the memory, so wrapping it in a QByteArray 
does not work (and copying to a new QByteArray just for mimetype detection 
looks like failing), storing to a temp file is also too much data copying for 
that purpose IMHO.

Looking at the implementation of KMimeType one can see that in the background 
all the find*() methods with files and QByteArray are passed to a function 
taking a QIODevice. Now, if KMimeType itself would also offer some overloaded 
functions with a QIODevice, I could just write a simple (readonly) QIODevice 
subclass for the Okteta data structures and have my problems solved.

So I have sent in a patch for review which does just this, adding some methods 
overloaded with QIODevice to the KMimeType class as described. If you, Ark 
developers, or anybody else is interested in this, please have a look at [RR] 
and add your comments, thanks :)

[RR] http://reviewboard.kde.org/r/1696/

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta