porting kfilemetainfo to strigi

Brad Hards bradh at frogmouth.net
Mon Jan 15 11:07:28 GMT 2007

On Monday 15 January 2007 04:26, Jos van den Oever wrote:
> - Strigi only support extraction of text.
> This is not enough and I will add more types. KFileMetaInfo can handle
> QVariants. This is overkill for Strigi and would be a lot of work to
> support. I'm not sure how many types I will support, but a binary
> string will certainly be added.
> Currently, for each field, the following function is called:
>  setField(const Indexable*, const std::string& fieldname, const
> std::string& value)
> I want to add this function:
>  setField(const Indexable*, const std::string& fieldname, void* ptr,
> size_t size)
> for binary data.
std::string? Why not QString? The field name might be localised.

> This leaves the need for integer and float types. These can be
> represented as strings and this is how fields like width and heigth
> are currently being represented.
I am a bit concerned about this - it appears to be a loss of functionality 
over KDE3. Not having numbers makes it harder to do smart things with 
comparison, and no QImage makes it harder to handle thumbnails.

I would prefer to see the existing capabilities maintained, and if Strigi 
wants a text string to index, then it should just create its own.


More information about the kde-core-devel mailing list