Making KFileMetaData a framework

Kevin Ottens ervin at
Tue Aug 12 18:41:26 UTC 2014

On Wednesday 06 August 2014 17:47:49 Milian Wolff wrote:
> > > Though note that the above does not mean that a call to extract would be
> > > async. It would still be sync. But you could use QFile and its readyRead
> > > signals internally to process stuff asynchronously and then emit the
> > > data once  the end of the file is reached. If the signals are there (see
> > > above) this could be done without changing the API and thus could be
> > > done later.
> > 
> > With Qt we have QFile and readReady signals so this can be done. But a lot
> > of the extractors use third party libraries which are quite often
> > synchronous.
> Right, then imo just leave it as-is but still add some signals which make it
> simpler to use the code as a worker object in a thread. At least, that's my
> opinion. Not sure what Kevin has to say in that regard.

My opinion is that the threading shouldn't be forced on the client code. So I 
would say: signals for the API. If you reuse something third party which 
doesn't even allow for polling then the thread should probably be in the 

In other words: hide the constraints from the third party libraries you are 
forced to use, don't leak them to your users.

Kévin Ottens,

KDAB - proud supporter of KDE,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the Kde-frameworks-devel mailing list