Hi all,
in my effort to implement a kioslave I'd like to make the user see a set of "virtual" folders when it opens an url. I've got a few doubts:

1) in my listDir method I placed something very simple like:

Code: Select all

void RoleFS::listDir( const KUrl& url ){
  kDebug(7000) <<  "[Entering RoleFS::listDir] URL = " << url.toMimeDataString();
 
 
  KIO::UDSEntry dirEntry;
  dirEntry.insert( KIO::UDSEntry::UDS_NAME, "TEST" );
  dirEntry.insert( KIO::UDSEntry::UDS_FILE_TYPE, 1 );
 
  // emit a signal to list this entry
  listEntry( dirEntry, true );
 
  finished();
  kDebug(7000) <<  "[Exiting RoleFS::listDir]";
}




is this correct to display a volder with the name test? Moreover, where can I find the UDS_FILE_TYPE right values? Do I also have to emit finished each time I exit the method?

2) how can I make the execution of listDir? I mean, if I place into konqueror my protocol rolefs:/// I see the execution of get(), that is the following very simple:

Code: Select all

void RoleFS::get( const KUrl &url ){
  kDebug(7000) <<  "[Entering RoleFS::get] URL = " << url.toMimeDataString();
 
  QByteArray array( "ROLEFS-WORKING-NOW-FOREVER!" );
  mimeType( "text/plain" );
  data( array );
  finished(); // success
  kDebug(7000) <<  "[Exiting RoleFS::get]";
}


and therefore I see the data emitted by the "cat" action. How can I instrument the slave to browse not to a single file but a set of folders? I've read the file.cpp and file_unix.cpp but it is still not clear to me.

Thanks.

If this information is not available in the API documentation (located at api.kde.org) or in the examples module on KDE Git (projects.kde.org/kdeexamples)

bcooksley wrote:If this information is not available in the API documentation (located at api.kde.org) or in the examples module on KDE Git (projects.kde.org/kdeexamples)

Sorry I don't get your comment. I think my doubts are related to understanding the life cycle of ioslaves, that is when events are generated and therefore which methods are called. I've elaborated a little more my slave creating the stat implementation, that returns the same result as the listDir one, which is that of displaying a folder. The point is: how can I see this? Since no matter what URL I write, the get method is always called.

Code: Select all

void RoleFS::listDir( const KUrl& url ){
  kDebug(7000) <<  "[Entering RoleFS::listDir] URL = " << url.toMimeDataString();

  KIO::UDSEntry dirEntry;
  dirEntry.insert( KIO::UDSEntry::UDS_NAME, "TEST" );
  dirEntry.insert( KIO::UDSEntry::UDS_FILE_TYPE, S_IFDIR );
 
  // emit a signal to list this entry
  listEntry( dirEntry, true );
 
  finished();
  kDebug(7000) <<  "[Exiting RoleFS::listDir]";
}


void RoleFS::stat(const KUrl& url)
{
    KIO::UDSEntry dirEntry;
    dirEntry.insert( KIO::UDSEntry::UDS_NAME, "TEST" );
    dirEntry.insert( KIO::UDSEntry::UDS_FILE_TYPE, S_IFDIR );
    statEntry( dirEntry );
}



I add also that my purpose is to provide different folder views over and existing file system, so that when the root is called (rolefs;///) I need to display initial folders, and then the filesystem folders as the user descend a folder. Sounds similar to audiocd (I cannot find the soure in the kde source tree).

Unfortunately, I have never written a KIO slave myself. I am not sure exactly of the lifecycle of a KIO Slave - but I do know that they can be used to satisfy multiple requests.

As for the audiocd slave sources, they are in the kdemultimedia module in SVN.
http://websvn.kde.org/trunk/KDE/kdemult ... e/audiocd/

At last I made some progress. The problem was about a wrong .protocol file around the system that was preventing me to list the directories (it had not the listing option).

However there is still something strange that I cannot understand: if I call a slave with a folder path the listDir method is called once for each directory in the path. For instance calling it with the path /home/luca
makes the listDir method to be called with the URL /, /home and /home/luca. Is this normal or do I have some error in my code?

This is likely Dolphin itself doing this, for some internal reason (possibly the breadcrumb).