[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: howto feed konqueror  with a kfileItem list ?
From:       xavier helluy <xavier.helluy () web ! de>
Date:       2005-05-23 9:33:37
Message-ID: 200505230933.37845.xavier.helluy () web ! de
[Download RAW message or body]

>> If I have an ioslave which can create a list of KFileItems, including
>> mimetype/ \ modification time / metadata / preview.
>
>That's not how ioslaves are supposed to work :)
>
>> My problem is: how can I pass this list of items to konqueror or to the\
>> openFile-dialog listView ?
>
>You can't.
>
>> What is easy to do is to return, via KIO::listDir a list of UDSEntries,
>> which\ contains mimetype and modification time,  but not the metadata, or
>> the preview.
>
> Which metadata do you mean?

I need to explain what I am doing.
I have  a  search-ioslave for indexed files. The protocol of the ioslave is 
"clucene". During indexing, I store on disk the preview of the files and in
 a database the content of the UDSEntries. When a user starts a new search,
 the ioslave works a bit like this:

User input:
      clucene:/search?query=blabla

If some of the indexed files are matching the query, the ioslave reads the
 database and  reconstruct the UDSentry of each matching file. Then it
 returns a KIO::listDir of KIO::UDSEntries.
- each KIO::UDS_URL is exactly the URL of the matching files, protocol
 included. For example :
       KIO::UDS_URL == file:///lalilala.pdf

- the KIO::UDS_MIME_TYPE would be here
     
       KIO::UDS_MIME_TYPE == application/pdf

I've _hoped_  that this would mean that the ioslave can pass to konqueror the
 complete UDSEntry (URL included protocol ("file","ftp"), mimetype,...) of
 the matching files without ever calling "sys/stat" or a "sys/file" or a
 kio::mimetypeJob,... (in fact it  seems that "stat" is still called, because
 I see broken links when the file does not exist) Further more the ioslave
 reads in the database  the location of the stored preview (if it exists) of
 the matching file and set the icon of the file to be equal to the preview
 (it is a hack ;-)  ).

This is what the ioslave does so far. But I would have liked to go further
 and to be able to provide the KFileMetaInfo from reading the database  too.

>Sounds like you need a protocol-specific KFilePlugin.

This means that  the way I do it above should sound wrong to you.
Using a protocol-specific KFilePlugin (what ever it is) would mean, if I
 understand your suggestion, that the protocol of the returned items should
 remain "clucene" and not be "file" or whatever. So I think you suggest:

- URL of the UDSEntry of a matching item should be:
         KIO::UDS_URL == clucene:result?URI=file:///lalilala.pdf
and
         KIO::UDS_MIME_TYPE == application/pdf

Then, to let the user read/open the file I would have to use a
 ioslave-redirection, isn't it ? Like this:
- the user opens the item, the ioslave receives a kio::get call, I catch it 
 and do a redirection in mySlave::get to: file:///lalilala.pdf
This means, I need to reimplement copy, move, delete, ...
But:
1. will konqui context menu work ?
2. and now, how can I provide the stored KFileMetaInfos ? I feel lost. How
 can I tell a KFilePlugin to be protocol specific ? 3.furthermore, I believe
 that the KFileMetaInfoJob needs to _read_ the virtual file, so it will sends
 a kio::get call exaclty like the kio::get call sent by the user who wanted
 to open the file. How can the clucene ioslave know what to do : redirection
 or KFilePlugin magic ? And what kind of magic ?

>And a plugin for kio_thumbnail for previews (implementing the ThumbCreator \

servicetype).

?? me lost already with how to use KFilePlugin :-((

> So howto return the full KFileItem info ? Could one hack the kdirlister
> cache, and \ add the created items to the cache ?  Those items would then
> be found in the cache \ and kde would not try to regenerate the metadata
> and all the rest ?  Does it makes \ sense ? How would one do that ?
>
>Hmm, do you really want to make a custom version of KIO?
>What you want to do here can't be done with kdelibs-3.x, since we can't
>change the ioslave<->application communication while keeping binary
>and behavior compatibility.
>
>However it raises an interesting suggestion for KDE4: since I plan to
>use a QHash<int,QVariant> for the UDS entries, it would indeed be

possible for a kioslave to provide a QImage of the preview for a file,

>if kio gets support for that.

Would it be like extended UDSEntries ?
    KIO::UDS_ICON_NAME  (we have)
    and
    KIO::UDS_PREVIEW_NAME (we want)
That would be nice.

Then one could have too:
   KIO::UDS_METAINFO_NAME
   where name would be the URL of a custom KIO::job returning a KFileMetaInfo
 object when called example:  KIO::UDS_METAINFO_NAME :=
 clucene://metainfo?get=file::///lalilala.pdf

Is this a crazy idea ?

Anyway, thanks for the help :-). 
And sorry if I am so confused about KFilePlugins :-(

--
XH  
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]